For a cyber insurance application, renewal, client security review, or NIS2 assessment, prepare evidence that shows how backup and patching controls operate. Approved policies, dated reports, exception records, and recovery tests help substantiate questionnaire answers and identify gaps before submission.
This guide helps internal IT teams and managed service providers (MSPs) assemble a repeatable evidence package, with German regulatory context. Insurer requests vary by policy and risk profile. Backup and patching are only part of NIS2 compliance. This article provides general preparation guidance, not legal or insurance coverage advice.
The five evidence categories to prepare
Organize backup and patching evidence into five categories:
- Policy: approved, current documents stating what should happen
- Configuration: how tools and architecture are set up
- Operating reports: dated, exportable records of what happened
- Exception records: documented gaps, compensating controls, approvals, and remediation
- Effectiveness tests: restore tests and remediation validation showing the controls work
Why cyber insurance and NIS2 reviews focus on evidence
There is a difference between asserting that a control exists and demonstrating that it operates. A policy tells a reviewer about your intent. It does not show that last Tuesday’s backup job finished, that the finance server was included, or that a critical patch reached every endpoint.
Insurer questionnaires can ask about backup protection, recovery testing, and security updates. A published Hiscox German questionnaire illustrates these topics, but its older wording should not be treated as current terms for any policy. Obtain the version that applies to your application or renewal.
For internal IT teams and MSPs, retaining evidence during normal operations makes it easier to answer review questions accurately and explain unresolved gaps.
How cyber insurance and NIS2 requirements differ
Insurance underwriting and regulatory compliance can use some of the same evidence, but they must be assessed separately.
Cyber insurance underwriting assesses risk against an insurer’s criteria. The application, policy wording, endorsements, and agreed conditions determine what you must represent or maintain. A general checklist cannot establish eligibility or coverage.
NIS2 Article 21 requires appropriate, proportionate cybersecurity risk-management measures for in-scope entities. These include backup management and disaster recovery, vulnerability handling, and procedures for evaluating control effectiveness. The directive does not prescribe one universal evidence package for every organization.
Germany’s NIS2 implementing law took effect on 6 December 2025. Section 30 BSIG requires covered important and particularly important entities to implement suitable, proportionate, effective technical and organizational measures and document compliance. Its requirements include backup and recovery, vulnerability management, and evaluation of effectiveness. Confirm your entity’s scope and any applicable sector-specific rules.
More detailed rules apply to certain in-scope digital-service entities, including MSPs, managed security service providers, and cloud providers. Commission Implementing Regulation (EU) 2024/2690 specifies backup and patch-management requirements, including documented recovery-test results and justified decisions not to apply patches. ENISA provides supporting implementation guidance and evidence examples; that guidance is not itself legislation.
This checklist covers two control areas. Full NIS2 compliance also involves governance, incident handling and reporting, supply-chain security, access controls, and other obligations. Insurance eligibility is not proof of regulatory compliance.
Examples of backup and patching evidence
Use the same five categories for both controls. These are practical examples to adapt to your environment and review requirements, rather than a prescribed regulatory template.
| Category | Backup evidence | Patching evidence |
| Policy | Scope, frequency, retention, ownership, recovery objectives | Prioritization, deadlines, testing, ownership |
| Configuration | Storage separation, access controls, encryption, deletion protection | Asset coverage, schedules, deployment rings, approvals |
| Operating records | Job histories, missed jobs, alerts, remediation tickets | Deployment history, overdue updates, failures, pending restarts |
| Exception records | Unprotected or excluded systems, risk, owner, corrective action | Deferred patches, risk, compensating controls, approval, review date |
| Effectiveness tests | Restore results against recovery objectives and usability criteria | Post-deployment checks or rescans, with retests where needed |
Link each report or test result to its policy, system scope, and responsible owner.
Backup evidence to prepare
Start with scope and ownership. Identify the systems, endpoints, applications, cloud services, and data stores that need recoverable backups, and assign an owner to each. Record exclusions and clarify the division of responsibility between your team, an MSP, and any cloud provider.
Document storage separation, access controls, encryption, retention, and protection against deletion or alteration. Record offline or immutable copies where used, their retention settings, and who can change them. Immutability limits alteration during a defined period; it does not mean a copy is offline. Confirm the protections required by your policy and applicable rules.
Backup evidence checklist
Prepare the following, adjusted to the insurer’s or assessor’s request:
- Approved backup policy with scope, frequency, retention, ownership, and recovery objectives
- Architecture and configuration records showing separation, access protection, and deletion safeguards
- Dated job reports showing protected assets, failures, missed jobs, and the age of the latest successful backup
- Failure alerts and remediation tickets, including unresolved issues
- Exception log for excluded or unprotected systems, with risk, owner, and corrective action
- Restore-test records, including outcomes and any corrective actions or retests
What a restore test record should show
A successful backup job does not establish that an application or service can be recovered. Test recovery against defined objectives: the recovery point objective (RPO) is the target maximum acceptable data loss measured in time; the recovery time objective (RTO) is the target time to restore service. Record:
- Test date, scenario, scope, and systems or data tested
- Backup copy and recovery point used, including its age
- Recovery method, environment, and required dependencies such as credentials or encryption keys
- Pass or fail against defined criteria, including data integrity and application usability
- Actual recovery time and recovered data point compared with the RTO and RPO
- Failed steps, corrective-action owner and deadline, and retest outcome
- Test owner and business or technical approver
Record test limitations. A successful file restore does not prove full service recovery. A failed test needs risk assessment, corrective action, and retesting; documentation alone does not resolve the weakness. Where Regulation (EU) 2024/2690 applies, regular recovery testing and documented results are explicit requirements.
Patching evidence to prepare
Patching evidence begins with an asset inventory and a clearly defined scope. Reconcile patch-tool coverage with the wider inventory, and identify unmanaged, offline, unsupported, and otherwise unassessed assets. Include relevant servers, endpoints, network devices, operating systems, and applications, even when their evidence comes from separate tools.
Document how you prioritize by known exploitation, exposure, business impact, and severity. State deployment deadlines, the event that starts each deadline, testing and emergency-change procedures, maintenance windows, and rollback arrangements. Use the applicable contract and legal requirements when setting timelines; this guide does not prescribe a universal deadline.
For entities covered by Regulation (EU) 2024/2690, patch procedures must address timely application, testing before production, trusted sources, and integrity checks.
Patching evidence checklist
- Patch policy with prioritization criteria, deadlines, and exception handling
- Asset inventory reconciled with patch-tool coverage and supported software
- Patch configurations, schedules, deployment rings, and approval records
- Dated patch compliance report with scope and calculation method
- Missing-patch, overdue-patch, and failed-deployment reports
- Deployment history, including installation dates and pending restarts
- Remediation tickets for failed or overdue updates
- Exception register with compensating controls and review dates
- Post-deployment checks or rescans confirming the fix is effective
State whether the compliance percentage measures devices or individual updates and define the numerator and denominator. Show asset coverage separately from compliance with patch deadlines. List approved exceptions, unknown status, unsupported systems, pending restarts, and overdue items with owners. An installation status alone may not establish that the vulnerability is resolved.
How to document patching exceptions
A system may require a delayed update or another mitigation, for example when a patch is unavailable or creates unacceptable operational risk. Document the decision and the remaining exposure. Each exception record should include:
- Affected asset, vulnerability or update, and business service
- Reason for the exception and supporting assessment
- Risk assessment, including exposure and the risk remaining after mitigation
- Compensating controls and evidence that they are implemented
- Accountable owner and authorized approver
- Review or expiry date and escalation criteria
- Remediation target and validation or retest result
Internal risk acceptance does not waive a legal duty or amend insurance terms. Where Regulation (EU) 2024/2690 applies, a decision not to patch must meet its conditions, be substantiated and documented, and include additional measures and acceptance of residual risk.
How to build an evidence package for review
Map each questionnaire answer or applicable requirement to supporting records. Keep a repeatable evidence index with the following fields:
| Field | What to record |
| Requirement and scope | Question or control reference, entity, service, and assets covered |
| Evidence owner | Person accountable for producing and maintaining the record |
| Reporting period | Dates covered and the report generation timestamp |
| Source and format | Source system, filters, calculation method, and export format |
| Reviewer | Person who checks accuracy before submission |
| Storage and retention | Secure location, access permissions, and retention period |
| Version and open gaps | Version submitted, unresolved issues, owner, and next review date |
Use these practices to keep the package accurate and usable:
- Retain dated source exports and supporting tickets. Screenshots can show settings, but record their date, system, and context. Use the format the recipient accepts; an export is not automatically more reliable than a screenshot.
- Confirm scope and requests first. Obtain the current questionnaire and applicable policy terms, then agree the reporting period and required formats. Do not assume the insurer and regulator need identical materials.
- Validate answers against actual operation. Have the relevant control owners and advisers review material representations. Disclose unresolved gaps accurately; documentation does not guarantee acceptance or coverage.
- Share securely. Keep original records under access control and provide only the information needed by the authorized recipient. Redact unnecessary personal or customer data, while preserving enough detail to substantiate the evidence. Never include passwords, tokens, or private keys.
- Refresh on a planned cadence and after material changes. Set retention periods against legal, contractual, and operational needs, and preserve a version of the package actually submitted.
For internal IT teams, assign an accountable owner for the review cycle. For MSPs, separate client evidence by tenant and record who operates, reviews, and approves each control. A client’s package should not expose another client’s information. Keep evidence for the MSP’s own regulatory obligations distinct from evidence delivered to clients.
Common evidence gaps to resolve
- Policies that describe controls the tools are not actually configured to enforce
- Backup jobs reported as “successful” with no restore test behind them
- Patch percentages that omit unmanaged or unknown-status assets without explaining the scope
- Exceptions that live in someone’s inbox rather than a register
- Evidence with no date, owner, or source system
- Configuration screenshots with no evidence of operation or testing
- Reports that were generated once and never refreshed
How unified endpoint operations can simplify evidence collection
Evidence gets fragmented when inventory, patching, and backup live in separate tools with separate reports. Reconciling them by hand is slow and error prone.
Platforms that combine endpoint management, patching, and backup can reduce manual reconciliation for supported, enrolled devices. Verify the reports available for your configuration and subscriptions. Supplement them with evidence for cloud services, network devices, applications, and other assets outside the platform’s coverage. Finding unmanaged devices may require separate discovery and inventory reconciliation.
Tooling can support evidence collection, but it does not establish NIS2 compliance, guarantee insurance coverage, or promise lower premiums. The organization remains responsible for scope, accurate representations, control effectiveness, and unresolved risks.
