上个月去一家制造企业做测评前的预检查，对接的是 IT 经理。他开场就问我：我们这个月要加班到几点？我说，你先别想加班的事，你先想想有哪件事现在做还来得及。
很多人把等保测评当成一场考试，临到考前才开始抱佛脚，整材料、补制度、追日志。真正拖后腿的从来不是文档，是技术面上那几件早该做却没做的事。
到底应该先忙什么？按自己做项目的习惯，列了四件。
我见过太多企业的资产清单是几年前整的，里面的 IP 早就换了三轮。测评师一进来就会发现：你说这台服务器不存在，扫描器却能扫到它。这种不一致，直接影响后面所有结论的可信度。
具体要核对的是三件：
这件事看上去不技术，却是整个测评的地基。地基没打好，后面写再多整改方案都是空的。
实操建议：用一个简单的表格过一遍——设备名、IP、所属系统、等级、负责人。宁愿粗一点，也要准。
这一条几乎是每次预检查都会中招：
离职同事的账号还活着
共用账号没有定期换密码
管理员账号在多个系统重复使用
这些问题单独看都不大，但扫描器不看情面。只要密码弱，它就能进去，它不管这个账号到底是谁在用。
默认密码这件事特别容易被忽略：设备买回来开箱就用，谁都觉得不会有人来扫。可偏偏每次扫描都能扫出一批。
具体动作：离职人员账号当天突断，默认密码强制修改，管理员账号开双因素。难的不是技术，是流程——得有人定期去查。
很多企业都有日志系统，但你让他调上一个月的登录记录，他调不出来。要么没开审计策略，要么存储只保留了一周。
这个细节很容易被忽略，但一旦真出事，没有日志就等于无从查起。这也是测评时最常见的扣分项。
稳的做法：把关键系统的登录、操作、异常事件统一汇到日志平台，保留至少六个月，并做好时间同步。
很多单位的应急预案写得很漂亮，但从来没有人跑过。真出事的时候才发现，预案里写的联系人已经调岗了。
建议至少在测评前组织一次演练：假设某台服务器被控——
演练的重点不是看大家反应快不快，而是看流程能不能走通。很多时候卡住的不是技术，而是到底该由谁拍板断网。
等保不是一次性的考试，它是一次体检。体检前一个月把上面四件事做到位，很多问题就不会留到测评那天。
真到了测评当天才发现的问题，往往早就存在了很久，只是没人碰。
如果你正在准备等保，欢迎把这篇转给你的 IT 同事。
