| 内审检查表（检查时间范围8.1--8.31） | |||||||
| 序号 | 明细分类 | 事项 | 检查具体事项 | 负责人 | XX系统反馈 | 是否提供资料 | 部门 |
| 1 | 权限管理 | 开发人员是否存在职责未分离的情况 | 提供开发人员权限清单 | 否 | 研发部 | ||
| 2 | 系统管理 | 系统开发立项是否通过线下立项会议进行讨论，会后是否将会议结果形成《立项说明书》等文档，通过钉钉或邮件由相关负责人审批 | 提供系统开发相关文档，以及相关文档审阅截图 | 否 | 研发部 | ||
| 3 | 系统管理 | 系统测试过程所产生的文档是否留存，测试结果是否通过钉钉或邮件发送给相关负责人审批 | 提供系统测试文档，以及相关文档审阅截图 | 否 | 测试组 | ||
| 4 | 系统管理 | 系统上线发布前是否通过钉钉进行审批 | 系统上线发布审批流程截图 |
否 | 研发部 | ||
| 5 | 批处理管理 | 批处理/定时任务发布时是否进行审核 | 批处理/定时任务清单以及审核截图 | 否 | 研发部 | ||
| 6 | 变更管理 | 系统变更时需求发起人是否通过钉钉或邮件提出变更申请，由业务部门审批抄送给部门总监和系统管理员。如有系统变更需求提出前需通过线下会议方式与技术部同事进行沟通，由技术部产品经理、开发人员、测试人员共同商议需求可行性，是否保留书面会议纪要及系统变更需求钉钉或邮件申请审批记录。 | 提供系统变更申请审批流程截图 如需要进行线下会议，需提供会议纪要和系统变更需求审批记录 |
否 | 研发部 | ||
| 7 | 变更管理 | 系统发生紧急变更直接由部门总监进行钉钉或邮件审批，在紧急变更之后业务部门需求发起人是否以钉钉或邮件形式向业务部门负责人补提申请并抄送给部门总监及系统管理员，并保留相应的变更审批记录; | 系统紧急变更需求申请审批流程截图 | 否 | 研发部 | ||
| 8 | 变更管理 | 系统变更验收由系统负责人以钉钉或邮件形式通知相关需求方并得到需求方回复 | 提供系统变更验收审批流程截图 | 否 | 研发部 | ||
| 9 | 变更管理 | 系统变更后是否经过测试服务器测试，上线发布时是否经过系统需求方钉钉或邮件审批 | 系统变更测试记录 系统变更上线发布审批流程截图 |
否 | 研发部 | ||
| 10 | 变更管理 | 系统发生变更后，需要对系统的版本号进行变更，并记录。系统版本号样例：V2.1.20210813.01 (2.1是系统的大小版本号，20210813是发布日期，01是当天发布的第几次) | 系统版本号更新记录 | 否 | 研发部 | ||
| 11 | 密码管理 | 应用系统密码策略：密码长度：8-32个字符；密码复杂度：包括大写字母、小写字母、数字、特殊字符中的至少三种；密码有效期为90天。 |
应用系统密码策略截图 | 否 | 各系统组 | ||
| 12 | 权限管理 | 应用系统管理员是否每半年对应用系统账号权限进行检查，检查是否存在冗余账号、冗余权限、用户权限是否职责分离且与职责相符等，检查结果是否以邮件形式发送给应用系统管理员所在部门直属上级审批。检查过程中发现异常情况，是否由应用系统管理员以邮件形式向对应系统负责人进行汇报，经过对应系统负责人和应用系统管理员所在部门直属上级共同确认后，由应用系统管理员在系统中删除冗余权限，对于职责不符账号，取消不符合职责的权限等； | 应用系统账号权限审核截图 | 否 | 各系统组 | ||
| 13 | 日志管理 | 运维人员每个月是否对应用层面日志进行检查，检查结果是否进行审阅 | 应用层面日志检查记录以及检查结果审阅截图 | 否 | 各系统组 | ||
| 人力资源部、运维组、数据组 | |||||||
| 序号 | 明细分类 | 事项 | 检查具体事项 | 负责人 | 反馈 | 部门 | |
| 31 | 安全区域 | 当离开办公桌时应锁上抽屉、柜子。所有涉及关键或敏感信息安全的纸质文件和资料在离开办公桌时，都应锁在文件柜里 | 现场检查 | 人力资源部 | |||
| 12 | 权限管理 | 员工办理入职手续，人事专员根据员工材料录入到EHR系统中，同时在系统勾选需要创建系统账号的员工，点击创建为用户，整理汇总员工信息表，在钉钉起草应用系统账号权限申请流程审批，审批通过后由 IT产品助理在系统权限群通知相关系统负责人配置，系统负责人按照审批通过的系统权限清单， 各系统负责人创建权限 |
1、EHR系统中员工系统账号清单、 2、应用系统账号权限申请审批截图、 3、配置完成之后的系统账号权限清单 |
人力资源部 | |||
| 13 | 权限管理 | 对于员工入职一周以上需要再增加权限，业务部门需要在钉钉发起应用系统账号权限申请流程审批，信息中心IT产品助理督促该系统负责人配置权限，权限配置好，各系统负责人钉钉流程回复业务部门。 | 应用系统账号权限申请审批截图、权限配置好各系统负责人回复业务部门的钉钉流程截图 | 人力资源部 | |||
| 14 | 权限管理 | 员工转岗权限变动由人事专员在OA系统中收到 “员工转岗晋升申请”，在EHR系统进行维护。整理汇总员工信息表，在钉钉起草应用系统账号权限申请流程审批。由 IT产品助理通知各个系统负责人。系统负责人按照审批通过的系统权限清单， 各系统负责人创建权限。IT产品助理发送该岗位系统权限清单给人事专员和业务部门负责人， | 1、员工转岗申请截图， 2、应用系统账号权限申请流程审批截图， 3、IT产品助理通知各个系统负责人记录， 4、变更后的岗位权限清单， 5、IT产品助理发送该岗位系统权限清单给人事专员和业务部门负责人的记录 |
人力资源部 | |||
| 15 | 权限管理 | 员工离职管理 - 员工向人力资源部提交审批后的离职资料，人事专员根据资料修改在EHR中修改人员状态为离职，整理离职名单，在钉钉起草应用系统账号权限申请审批流程。审批完成后由信息安全管理岗核查离职人员名下的系统清单，通知各个系统负责人进行系统账号停用，系统权限停用后，将该岗位的系统权限清单发送给人事专员和业务部门负责人 | 1、检查员工离职手续单 2、查看人事专员是否在EHR中修改人员状态，查看离职名单 3、查看是否在钉钉起草应用系统账号权限审批流程，并提供审批截图 4、离职员工名下的系统清单，员工停用系统权限账号清单 |
人力资源部 | |||
| 16 | 权限管理 | 客服部门保留账号需求—客服员工离职，1、如需保留此账号继续向客户跟进催款、处理异常件，客服经理（华南负责人许伟奇 、华东北负责人杨丽芳）提交需要保留的账号以及停用时间给人力资源部标准专员，标准专员暂不发送员工离职信息表给信息安全管理岗办理账号停用，等到停用时间再发送离职信息表给到信息安全管理岗； 2、新入职员工接手离职人员账号需要客服经理督催接收此账号的新员工更改密码。根据员工熟悉业务的情况做出判断，如果新员工能接手此业务，客服经理在钉钉起草应用系统账号权限申请流程审批，IT 产品助理更改此账号用户名称 |
1、需要保留的账号清单（需注明停用时间） 2、接收应用系统账号权限申请流程审批截图 |
人力资源部-彭玮 | |||
| 19 | 密码管理 | 数据库密码策略：密码长度：8-32个字符；密码复杂度：包括大写字母、小写字母、数字、特殊字符中的至少三种；密码有效期为90天。 |
数据库密码策略截图 | 数据组 | |||
| 20 | 权限管理 | 数据库权限开通流程 | 数据库权限开通流程截图（需包含申请人、申请原因等信息、各审批节点人员姓名） | 数据组 | |||
| 21 | 权限管理 | 数据库管理员是否每月对数据库权限进行检查，检查其是否存在冗余账号、冗余权限，用户权限是否职责分离和职责相符等，检查结果是否以邮件形式发送给数据库管理员直属上级审批。检查过程中发现异常情况，是否由数据库管理员以邮件形式向对应系统负责人汇报，经过系统负责人和数据库管理员直属上级共同确认后，由数据库管理员删除冗余权限，对于职责不符账号，取消不符合职责的权限等 | 数据库权限审核截图 | 数据组 | |||
| 22 | 日志管理 | 每月对数据库运行日志进行检查，检查结果由数据组负责人进行审阅 | 数据库日志检查记录以及检查结果审阅截图 | 数据组 | |||
| 23 | 备份管理 | 是否对数据库备份保存期限进行规定 | 各系统数据库备份保存期限 | 数据组 | |||
| 24 | 备份管理 | 根据各系统备份情况，数据组DBA是否在每次执行备份后第二个工作日前，对每次备份情况进行检查，并对数据库备份执行情况进行记录，每周是否由DBA将备份检查结果以邮件形式发送给数据库负责人进行审批，并保留审批。 | 各系统数据库备份执行情况检查记录以及审阅截图 | 数据组 | |||
| 25 | 备份管理 | 每年对数据库进行两次数据恢复演练，由各系统相关人员参与，并对演练情况进行记录形成数据恢复演练报告，演练结束后，将结果以邮件形式发数据库负责人进行审阅。 | 1、数据库备份恢复演练记录以及结果审阅截图 2、参与恢复演练的人员清单 |
数据组 | |||
| 26 | 备份管理 | 每年是否至少进行两次数据库应急恢复，并形成应急恢复报告，对演练结果是否进行审阅 | 1、数据库应急恢复报告，应急恢复演练审阅截图 2、参与应急演练的人员清单 |
数据组 | |||
| 27 | 密码管理 | 操作系统密码策略：密码长度：8-32个字符；密码复杂度：包括大写字母、小写字母、数字、特殊字符中的至少三种；密码有效期为90天。 |
操作系统密码策略截图 | 系统运维部 | |||
| 28 | 权限管理 | 用户开通操作系统权限时进行钉钉审批，并经过相应部门领导审批，由系统运维部根据申请开通相应权限 | 操作系统权限申请审批截图（需包含申请人、申请原因等信息、各审批节点人员姓名） | 系统运维部 | |||
| 29 | 权限管理 | 操作系统管理员是否每半年对用户权限进行检查，检查其是否存在冗余账号、冗余权限，用户权限是否职责分离和职责相符等，检查结果是否以邮件形式发送给操作系统管理员直属上级审批。检查过程中发现异常情况，是否由操作系统管理员以邮件形式向操作系统管理员直属上级进行汇报，经操作系统管理员直属上级确认后，由操作系统管理员删除冗余权限。对于职责不符账号，取消不符合职责的权限等 | 操作系统权限审核截图或记录表 | 系统运维部 | |||
| 30 | 日志管理 | 每个月是否对操作系统日志进行检查，将检查记录和检查结果以邮件形式发送至相关负责人进行审阅 | 操作系统日志检查记录以及检查结果审阅截图 | 系统运维部 | |||
| 34 | 雇佣中 | 员工须对公司机密信息保密，不得将信息泄露给其他单位或个人。 | 1. 抽查保密协议； 2. 查看相关制度要求； |
人力资源部 | |||
| 35 | 雇佣中 | 对被录用人员的身份、背景、专业资格和资质等进行审查，对其所具有的技术技能进行考核； | 1) 应核查人员安全管理文档是否说明录用人员应具备的条件（如学历、学位要求，技术人员应具备的专业技术水平，管理人员应具备的安全管理知识等）； 2) 应核查是否具有人员录用时对录用人身份、背景、专业资格和资质等进行审查的相关文档或记录，是否记录审查内容和审查结果等； |
人力资源部 | |||
| 36 | 漏洞扫描 | 对网络资产（包括终端、服务器与网络/安全设备等）进行全网安全漏洞扫描（扫描过程必须在非工作时段内进行并完成），并对检查出的安全漏洞进行修复；安全漏洞扫描工具可采用国内外安全厂家提供的安全漏洞扫描工具 | 检查漏洞扫描频率，漏洞修复记录 | 系统运维部 | |||
| 37 | 权限管理 | 服务器权限变更 - 以下情况对其访问权应予以注销，1.劳动合同终止；2.因岗位调整；权限变更应填写《用户授权申请表》，包括权限开放/变更/注销时间、变化后权限内容、开放权限的管理员。 | 1.检查用户授权申请表内容是否完整 2.当劳动合同终止或者岗位调整时是否对服务器的访问权限注销 |
人力资源部 | |||
| 38 | 任用前 | 录用人员应与公司签订劳动合同，且劳动合同:合同章、填写完整 | 抽查近期录用人员是否签订劳动合同，且合同章、内容填写是否完整 | 人力资源部 | |||
| 39 | 任用前 | 对聘用的员工上岗前做充分的背景调查 | 抽查近期录用人员是否有背景调查 | 人力资源部 | |||
| 40 | 任用终止和变更 | 应有明确的人员离职审批流程，确保人员离职前相关资料、文档、资产已收回，工作职责及内容已交接，所有的权限已撤销或挂起，并向离职人员重申保密协议的有效性 | 描述人员离职审批流程，确认人员离职前相关资料、文档、资产已收回，工作职责及内容已交接，所有的权限已撤销或挂起。 | 人力资源部 | |||
| 41 | 日志管理 | 对业务系统的用户操作进行日志记录，记录的内容包括但不限于时间、操作人、操作行为等，并确保日志不可删除或修改 | 检查业务系统的系统日志和堡垒机操作日志是否完整 | 系统运维部 | |||
| 42 | 日志管理 | 定期分析系统、网络日志，排查日志异常，及时发现异常并进行跟踪整改，保留过程记录 | 日志巡检记录表 | 系统运维部 | |||
| 43 | 审计管理 | 对系统运维部人员访问敏感信息的操作采取审计措施，记录操作时间、操作人员及操作内容，且指定人员落实操作记录审计工作 | 检查运维审计记录是否完整 检查方法：登录到堡垒机等审计设备，查看操作的日志记录是否完整，并且有专用的审计账号。 | 系统运维部 | |||
| 44 | 审计管理 | 审计记录采取权限控制措施，禁止修改、删除审计记录。因系统运维部需要对审计记录进行人工操作时，应先经审批授权后方可操作，并禁止修改审计记录以及删除未备份的审计记录 | 1、检查系统运维部人员账号是否具有修改审计记录的权限； 2、如需查看审计记录，提供书面审批证明； |
系统运维部 | |||
| 47 | 信息安全培训 | 至少每半年开展一次信息安全培训，并做培训记录。 | 1. 描述信息安全培训频次、负责人等信息 2. 查看培训记录 |
系统运维部 | |||
| 49 | 应急演练 | 应急演练相关记录应完整 | 1、检查演练操作记录，包含各步骤、方法、参与演练过程的人员签字、演练执行时间； 2、检查应急演练总结报告，内容和签字是否完整 |
系统运维部 | |||
| 52 | 制度管理 | 需建立机房管理制度，明确机房管理内容。包括机房人员、设备进出，操作及维护等管理制度 | 查看机房管理制度 | 系统运维部 | |||
| 53 | 制度管理 | 制度和流程发布前应得到内部审批，进行更新，并通过有效的渠道进行传达。 | 抽查制度和流程发布的审批记录、发布渠道 | 胡志芳 | 信息安全部 | ||
| 56 | 终端安全 | 涉及信息处理的计算机是应有安全控制措施，是否安装了终端文件加密软件。 | 涉及信息处理的计算机是应有安全控制措施，是否安装了终端文件加密软件。 |
系统运维部 | |||
| 64 | 组织保障 | 应根据其具体情况建立相应的负责灾难恢复的组织机构。 1.设立灾难恢复领导小组作为恢复工作的组织领导机构，组长由最高管理层成员担任； 2.设立灾难恢复规划实施小组，明确人员组成和职责定位； 3.设立时间应急响应小组，明确人员组成、职责定位和准确的联系方式； 4.设立专门部门对外解释，且作为客户、监管部门的沟通渠道 |
1、是否建立了负责灾难恢复的组织机构及其完整性。一般可分为灾难恢复领导小组，灾难恢复实施小组和灾难恢复日常运行小组。如果没有以上组织构，是否有相应的机制来保证灾难恢复过程的实施。 2、灾难恢复组织机构人员组成是否合理。组织机构内人员的职责是否明确，并指定相同职责的人员代替顺序。灾难恢复的组织机构人员的组成应包括管理、业务、技术和后勤方面的人员。 3、是否有明确的正式文件来规定灾难恢复领导小组的职责和分工。 4、 是否由最高管理层成员担任组长，并能够切实在灾难发生时迅速响应，同时建立了相应的人员备份机制。 5、职责定位的准确性。是否明确了包括审核并批准经费预算、 审核并批准灾难恢复策略、审核并批准灾难恢复预案和批准灾难恢复预案的执行在内的职责 范围，或以正式文件明确的类似的职责权限。 6、是否有明确的正式文件来规定灾难恢复实施小组的职责和分工，并明确了各重要职责的人员备份策略。 7、是否明确规定了灾难恢复规划实施小组的职责为：灾难恢复需求分析、提出灾难恢复策略和等划分、灾难恢复策略的实现、制定灾难恢复预案、 组织灾难恢复预案的测试和演练。或者有相类似的职责定义完成以上工作。 8.是否有建立事件应急响应组织，人员应急职责清晰，联系方式准确，并能够使服务人员及时获取。 |
系统运维部 | |||
关注公众号回复 管理模板 即可下载哦！
以下是星球专栏目录
如果觉得资料有用也可以分享到朋友圈让更多朋友下载！
右下角，您点赞和在看
小编工资涨2毛
原文始发于微信公众号（小毅安全阵地）：内审-资产评估-业务连续性检查表模板下载！
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论