网站被入侵后，责任不能简单按“网站是谁的”或“谁在维护”来划分，而应结合合同约定、各方对网站的控制能力、过错程度、因果关系及损失扩大情况综合判断。维护合同最需要写清的，不是一句“维护方负责网站安全”，而是安全边界：谁控制哪一层、谁应做什么、做到什么标准、发现问题如何通知、未做到如何担责。

第一，先划清技术与管理边界。网站安全通常涉及多个层级：基础设施层，包括云服务器、机房、CDN、域名、DNS、证书；系统层，包括操作系统、中间件、数据库、补丁；应用层，包括代码、插件、API、上传功能、开源组件；运营层，包括管理员账号、弱密码、内容发布、员工终端、钓鱼邮件；第三方服务层，包括支付、统计、客服、短信等。合同应逐项列明责任方。例如：云平台负责基础设施安全，开发方对交付代码漏洞负责，维护方负责约定范围内的补丁与巡检，客户负责账号权限、内容审核和员工安全。可采用“责任矩阵”写明谁执行、谁审批、谁配合、谁知情，避免出事互相推诿。

第二，合同要写可执行的安全义务。建议明确：维护范围与排除项；安全基线，如补丁时限、漏洞扫描频率、日志留存、备份策略、最小权限、多因素认证；客户配合义务，如及时提供权限、审核变更、禁止共享账号；第三方组件和开源软件的管理责任；事件响应机制，如发现入侵后多少小时内通知、如何止损、如何取证、何时提交复盘报告；数据泄露时的通知与合规配合；转包与分包限制；审计与交接要求。尤其要区分“努力义务”和“结果保证”：维护方通常承诺按行业合理标准履职，不宜轻易承诺“绝对不被黑”；但隐瞒漏洞、不按约修复、删除日志、延误通知导致损失扩大，则可能构成违约或过错。

第三，入侵后按路径定责。应查明入口：弱密码、未打补丁、代码漏洞、云配置错误、第三方插件、钓鱼或内部误操作。谁对入口负有控制义务，谁就更容易被认定存在过错。同时看减损义务：一方发现异常是否及时通知、是否隔离、是否保全证据、是否避免擅自重装导致日志灭失。若客户拒绝修复或继续使用弱密码，维护方已书面提示的，可减轻维护方责任；若维护方负责账号安全却未落实策略，则不能仅以“客户也有责任”免责。涉及个人信息泄露的，还应评估《网络安全法》《数据安全法》《个人信息保护法》下的报告与通知义务。

第四，限责条款要有边界。合同可约定责任上限、赔偿范围和保险安排，但故意或重大过失、数据合规责任、造成人身损害等情形，免责条款可能无效或受严格限制；格式条款还需履行提示说明义务。较稳妥的做法是：设置与合同金额相匹配的责任上限，同时列明例外情形，并要求维护方购买网络安全责任保险。

FAQ问答

1.合同只写“维护方负责网站安全”够吗？

不够。表述过于笼统，难以判断具体义务。应细化到系统、应用、账号、补丁、日志、备份、事件响应等层级，并写明标准和时限。

2.客户使用弱密码导致被入侵，维护方还赔吗？

看合同与过错。若维护方已提示、要求整改并落实多因素认证，客户拒绝配合，客户通常主责；若维护方负责账号管理却未执行安全策略，可能按过错比例担责。

3.维护方能否约定“网站被黑不赔”？

可以限制责任，但不能绝对免责。故意、重大过失、数据泄露合规责任等可能不能通过条款完全排除。建议采用责任上限、例外清单加保险，而非简单写“全不赔”。

4.被入侵后第一步做什么？

先隔离止损、保全日志和证据，按合同时限通知各方，评估是否涉及个人信息或重要数据，必要时报警或向监管部门报告。不要急于重装系统，以免破坏取证。

5.如何证明维护方已尽安全义务？

靠证据链：巡检记录、补丁记录、漏洞扫描报告、日志、变更审批、备份恢复演练、风险提示函、事件通知和复盘报告。合同应要求定期提交并留存这些材料。

总之，网站被入侵后的责任划分，核心是“控制力、过错、因果关系和减损义务”。维护合同应把安全边界写成可执行、可验证、可追责的条款，而不是一句空泛承诺。以上为一般合同与风险管理建议，不构成正式法律意见。