Which DORA required policies and documents must exist, and who approves them
When a regulator, customer or contract asks for DORA documentation, the answer starts with a defined set of policies and plans that the management body must approve. DORA names the core documents in its articles, and Delegated Regulation (EU) 2024/1774 sets out what each policy must contain. The first step is to confirm which documents your entity must hold, because the list depends on your type of financial entity and on proportionality. Check the documents named in Article 6 (the ICT risk management framework and digital operational resilience strategy), Article 9(4)(a) (the information security policy), Article 11 (ICT business continuity policy and response and recovery plans), Article 12 (backup policies), Article 14 (crisis communication plans), Article 17 (incident management process), Article 24 (testing programme), Article 28(2) (ICT third-party risk strategy), Article 28(3) (register of information) and Article 28(8) (exit plans). Read the full text of Regulation (EU) 2022/2554 alongside the RTS, not from a summary.
Your organization owns these documents and their approvals. The management body must formally approve the ICT security policies and the date of that approval must appear in them, so confirm who sits on that body and how its minutes will evidence each approval. Policies also need a named role or senior manager responsible for monitoring the arrangements, a methodology for deciding which ICT services support critical or important functions, and a yearly management body review. An implementation partner can draft, map and organize these documents and collect the evidence behind them, but the partner does not decide what your policies say or approve them. Confirm the drafting owner, the approver, and the review cycle for each document before work starts.
An independent auditor or the competent authority, not DeployOpen, judges whether your documents meet DORA and the RTS. DORA sets no certification scheme, so there is no certificate to obtain for the documentation itself. Ask your supervisor or auditor which format they expect, whether they accept a single consolidated framework or separate policy files, and how they want approval evidence presented. Plan for the documents to change: incidents, major system changes and the yearly review will all require updates, and each version needs its own approval record.
Which policies the RTS requires in the ICT security area
Articles 2 and 3 set the rules that every ICT security policy must follow, and they cover the ICT risk management policy itself. Together they decide how each policy fits into the wider framework, who answers for it and how often it is reviewed. Treat these articles as the wrapper around the rest of the set, because a policy without an approval date or a named owner will be questioned before its content is read.
- Embedding and alignment: Each ICT security policy sits inside the ICT risk management framework and links back to the information security objectives in the digital operational resilience strategy.
- Approval record: Each policy states the date the management body formally approved it.
- Indicators and exceptions: Each policy names indicators that show whether it is being applied, along with a record of approved exceptions.
- Roles and segregation: Staff responsibilities, the documentation to keep and the segregation of duties under the three lines of defence or another control model are written down.
- Review and ownership: The management body reviews the ICT risk management policy at least once a year, the policy sets a method for deciding which ICT services support critical or important functions, and it names the senior manager who monitors these arrangements.
Before approval, confirm that every policy in the set shows its approval date, that the named owner has authority to enforce it, and that the exception record has an owner who reports to the management body.
Articles 4, 6 and 11 cover what the organization owns, how its information is protected and how data and systems are kept secure. The asset management policy in Article 4 feeds the asset inventory, the encryption policy in Article 6 sets the rules for protecting data and the keys that unlock it, and the data and system security procedures in Article 11 turn these rules into daily controls. An assessor will often trace one system through all three to check that the records agree.
- Asset management (Article 4): Rules for how ICT assets are identified, classified, owned and retired, so that the inventory and the policy describe the same estate.
- Encryption (Article 6): Rules for protecting data in transit and at rest, with cryptographic keys covered by lifecycle rules for creation, storage, rotation and destruction.
- Data and system security (Article 11): Procedures for securing data and systems across their lifecycle, including classification, handling and secure configuration.
- Key ownership: A named role for each key store, along with a record of who can access keys and how that access is logged.
Check that the encryption policy names the systems where keys are held for each self-hosted platform, and that the asset records list the same systems under the same owners.
Articles 8, 12, 13 and 17 govern how ICT systems run day to day and how changes reach them. The operations procedures in Article 8 describe routine tasks, the logging procedures in Article 12 record what happened, the network security management policy in Article 13 controls traffic and connections, and the change management policy in Article 17 governs how modifications are requested, tested, approved and reversed. Together they let an assessor reconstruct how a system reached its current state.
- Operations procedures (Article 8): Documented steps for recurring operational tasks such as monitoring, job scheduling and service checks, with named owners for each.
- Logging (Article 12): Rules for which events are logged, how logs are protected from alteration, how long they are kept and who reviews them.
- Network security (Article 13): Controls for segmentation, traffic filtering and the secure management of network devices and remote connections.
- Change management (Article 17): A path for standard, urgent and emergency changes that covers testing, approval, back-out steps and a post-change record.
For each self-hosted platform, confirm that change records link to the asset inventory and that the log sources cover the admin interfaces, the database and the network boundary.
Articles 18 to 21 cover the physical environment, the people who work with ICT systems, and the identities and permissions they use. The physical security policy in Article 18 protects premises and equipment, the human resources policy in Article 19 addresses staff before, during and after employment, the identity management policy in Article 20 controls how accounts are created and retired, and the access control policy in Article 21 decides who may do what. These policies usually depend on each other, so the same joiner, mover and leaver process should drive all four.
- Physical security (Article 18): Controls for data centers, server rooms and equipment, including the rules that apply where a hosting provider runs the facility.
- Human resources (Article 19): Screening, security responsibilities written into roles, security training and a defined process for removing access when staff leave.
- Identity management (Article 20): Unique identities, an account lifecycle and rules for authentication, including the handling of shared and service accounts.
- Access control (Article 21): Least-privilege rules, approval steps for privileged access and a schedule for reviewing who holds which rights.
For a self-hosted platform, confirm that the contract with any hosting provider covers physical controls and that the identity records match the access review output.
Articles 10, 15 and 16 cover how ICT projects are run, how software is acquired, built and maintained, and how weaknesses are found and fixed. The vulnerability and patch management procedures in Article 10 handle known weaknesses in live systems, the ICT project management policy in Article 15 assesses risk before and during projects, and the acquisition, development and maintenance policy in Article 16 sets security requirements across the software lifecycle. For open-source platforms, these articles often carry the most day-to-day work.
- Vulnerability and patch management (Article 10): Procedures to identify weaknesses, rank them by risk, apply fixes and record the outcome, including the timing expected for each class of fix.
- Project management (Article 15): Risk assessment at project start, security requirements agreed with the business and sign-off before a project goes live.
- Acquisition, development and maintenance (Article 16): Security requirements for purchased and built software, testing before release and controls over third-party and open-source components.
- Upstream tracking: A named owner who follows vendor and community advisories for each component and records how each one was handled.
For each open-source platform, confirm who tracks upstream advisories, how patches are tested before rollout and where the test results are kept.
What every DORA policy must contain
Every ICT security policy under DORA must meet a common set of requirements set by Article 2 of Delegated Regulation (EU) 2024/1774, whatever its subject. First, the policy has to be embedded in the ICT risk management framework and aligned with the information security objectives in the digital operational resilience strategy, so a policy that stands alone outside that structure will not satisfy an assessor. Second, it must state the date on which the management body formally approved it. That date is evidence in its own right, so the approval record should be kept with the policy version history. Third, the policy must include indicators that monitor whether it is being implemented, a log of exceptions, the staff responsibilities it creates, and the documentation staff are expected to keep. Fourth, it must set segregation of duties under the three lines of defence or another documented control model, and it must show that leading practices and applicable standards were considered.
Article 3 of the same regulation adds two governance duties that apply to the whole set. The management body must review each policy at least once a year, so the review date and the minutes recording that review belong on the policy register. The policy must also name the role or senior manager responsible for monitoring the arrangements it sets out. Organizations often name a role in one document and a different person in another, which an assessor will treat as a gap. Before any policy goes to the board, confirm that the owner named in the policy matches the owner in the RACI, the risk register and the training plan. The same policy must also set a methodology for deciding which ICT services support critical or important functions, so that scoping decision is documented once and reused across the third-party and continuity documents.
A practical first step is to build a template that carries these common elements, then check each of the policies named in Title II of the regulation against it. Ask your legal, risk and internal audit teams to confirm how they will record approval dates and exceptions, because these two items are the most frequent sources of findings at review. If you plan to use an implementation partner to draft or structure the policies, agree in writing which parts it prepares and which parts management must approve. The organization owns the policy set and its approval. An independent auditor or competent authority assesses it.
How the incident, continuity and communication policies differ
Incident management, business continuity, backup and crisis communication are separate policies in DORA, each with its own articles and its own triggers. They interlock during a disruption, so the management body should approve them as a coherent set and confirm that each one names its owner, its scope and its review cycle.
ICT-related incident management policy
Article 22 of Delegated Regulation (EU) 2024/1774 requires the policy to document the incident management process from detection to closure. It must also keep a maintained list of internal and external contacts for threat and anomaly detection and vulnerability management, and it must analyse significant or recurring incidents and their frequency patterns. Check that the contact list is current, that a named role owns the process, and that the management body approves the policy with a stated date. Confirm the link to the reporting obligations in Chapter III.
ICT business continuity policy
Article 24 of Delegated Regulation (EU) 2024/1774 requires the policy to set objectives linked to the business impact analysis, along with scope, activation and deactivation criteria, and governance and escalation paths. It must also cover severe disruption scenarios, recovery time objectives (RTO) and recovery point objectives (RPO), and a testing and review cycle. Confirm that each critical function has an RTO and RPO traceable to the impact analysis, and that the policy names who may activate recovery.
Backup policy
Article 12 of DORA requires backup policies and procedures, along with restoration and recovery procedures and methods. The policy should define what is backed up, how often, where copies are held and how they are isolated from the production environment. It should also set how restoration is tested. Confirm that backup scope matches the objectives in the continuity policy, and that the owner of restoration testing is named in the policy rather than assumed.
Crisis communication policy
Article 14 of DORA requires crisis communication plans. Article 14(2) requires communication policies that separate staff involved in ICT risk management, particularly response and recovery, from staff who only need to be informed. The policy should name the spokespersons, the channels for internal and external stakeholders and the approval route for external messages. Confirm that the list of recipients is kept separate for each group, so responders receive operational detail while others receive status updates only.
Third-party documents: the strategy, register and exit plans
The third-party documents DORA requires are an ICT third-party risk strategy (Article 28(2)), a register of information (Article 28(3)) and exit plans (Article 28(8)). Together they show a regulator how the organization decides which providers it depends on, records those dependencies and plans to leave them. Start with the strategy, because the register and exit plans are only as useful as the decisions the strategy sets out. The strategy must be approved and kept current by the management body, and it should be reviewed against the methodology in Article 3 of Delegated Regulation (EU) 2024/1774 for deciding which ICT services support critical or important functions. That methodology is the step most teams underestimate: if it is vague, the register will either include everything or miss the providers that matter most.
The register of information is the inventory of contractual arrangements with ICT third-party providers. It is a structured record, and its fields and format are set by the technical standards that supplement DORA, not by the Article 28 text alone. Confirm the current template and required fields with your competent authority and against the regulation on EUR-Lex before you build tooling around it. Owners of self-hosted open-source platforms should note that the register must still list the providers behind those platforms, such as cloud or hosting vendors, support firms and managed service partners, even where the software itself carries no license fee. The same asset inventory and provider records should feed both documents so they do not disagree.
Exit plans are the least-built of the three documents. For each critical or important function, the plan should describe how the organization would move the service to another provider or bring it in-house, including data return, configuration export, key handling and the sequence of cutover steps. For a self-hosted platform, that means documenting where the data, backups and encryption keys sit, which components are portable, and how long a migration would take on your own infrastructure. Test the plan against a realistic scenario in which the provider fails or the contract ends, and record what you could not do. Confirm with your competent authority which level of detail and review frequency they expect, since the standards and supervisory practice define these points, not a single fixed template.
How the documents move from draft to management body approval
This sequence turns the policies and plans DORA requires into approved, dated and reviewed documents that staff can find and follow. Each phase leaves a specific output, so an assessor or supervisor can trace every document from its first draft to its latest review.
Inventory existing documents and owners
Collect every policy, procedure, plan and register already in use, then record the document name, version, owning function, last review date and the DORA article or RTS article it appears to address. Confirm the owner for each document in writing, because the function that drafts a policy is usually the one that must keep it current. The output is a document inventory with one named owner per item, which becomes the baseline for every later phase.
Run a gap check against the RTS articles
Compare the inventory with the document list in Delegated Regulation (EU) 2024/1774 and the DORA articles that name documents, such as the business continuity policy, the backup policy and the exit plans. Mark each required document as present and current, present but incomplete, or missing. The output is a gap register that lists each missing element, such as indicators, exception records or the methodology for critical or important functions, and assigns it to an owner.
Draft each document in the owning function
The owning function writes or updates the document using the common elements the RTS requires, including scope, roles and responsibilities, indicators, exception handling and documentation to keep. Drafts should link to the ICT risk management framework and the digital operational resilience strategy so the policies stay aligned. The output is a draft at version 0.x with a change log that states what was added and why, so reviewers can see the delta rather than rereading the full text.
Review by risk and compliance
Risk and compliance review each draft against the RTS requirement it claims to meet and check consistency with the other policies, the asset inventory and the register of information. Reviewers record comments in the change log and confirm that segregation of duties follows the three lines of defence or the control model the entity has chosen. The output is a reviewed draft with a signed review record, and any open points are logged as conditions for approval.
Obtain management body approval with the date recorded
The management body approves the ICT security policies and the other framework documents in a formal decision, and the approval record states the date of approval as the RTS requires for ICT security policies. The minutes or resolution reference the document name and version. The output is an approval record stored with the controlled document, and a version that is marked approved and cannot be edited without a new draft cycle.
Publish to staff and external stakeholders
Publish the approved documents to the people who need them, and communicate separately to staff who respond and recover and to staff who only need to be informed, as Article 14(2) of DORA requires for communication policies. Confirm each recipient group can access the version that applies to them and that superseded versions are withdrawn. The output is a distribution log and an access record showing who received which version and when.
Monitor implementation and keep exception records
Track the indicators defined in each policy, record every exception with its approver, reason and expiry, and feed incidents and test results back into the documents where they reveal gaps. The output is a monitoring report and an exception register that the owner reviews on a regular cycle, and that the management body can examine when it oversees the framework.
Review annually and repeat the cycle
The management body reviews each ICT security policy at least once a year, and the review log records the date, the reviewer, any changes and the reasons for them. Changes triggered by incidents, major system changes or new third-party arrangements start a new draft cycle before the next annual review. The output is a dated review log and a new approved version, which restarts the sequence from the inventory when scope or the regulatory baseline changes.
How to check the document set is complete before a supervisory request
A supervisor will ask for documents and then test whether they are current, approved and consistent with reality. The checks below let a compliance lead find gaps internally before a request arrives, starting with the document inventory and ending with comparison against live systems.
Map every document to an owner
Build a single register that lists each policy, plan, strategy and register DORA and its RTS name, with a named owner and the body that approves it. Include the information security policy, the continuity and response and recovery plans, the testing programme, the third-party strategy and the exit plans. A document without a named owner is the most common reason an otherwise complete set fails review. Confirm that each owner can explain the document and produce its latest approval record on request.
Check version and approval dates
Open each ICT security policy and confirm it states a version number, the date the management body formally approved it, and a link to the approval minute. Under Article 2 of Delegated Regulation (EU) 2024/1774, the approval date must be stated in the policy itself. Mismatches between the version in the register and the version in the file are a frequent finding, so compare both against the record of the approving meeting.
Confirm exception registers exist
Policies under the RTS must record exceptions. Check that a dated exception register exists for each policy, that every exception names an approver, a justification, a compensating control and an expiry or review date, and that expired exceptions have been closed or re-approved. An empty register is not evidence of compliance on its own. Ask whether anyone has been able to bypass a control and where that decision was recorded.
Confirm the annual review took place
Article 3 of Delegated Regulation (EU) 2024/1774 requires the management body to review the ICT risk management policy at least once a year. Pull the minutes for the last review cycle and confirm that the management body, not only a delegated committee, considered the policy. Check that each policy shows a review date that falls within the last twelve months and that any changes since the last review are traceable to a decision.
Verify the register of information
The register of information, required by Article 28(3) of DORA, must list the ICT third-party arrangements that support the entity's functions. Compare it against procurement records, contract files and the asset inventory to find arrangements that were signed but never recorded, or recorded services that have ended. Confirm the register's last update date and the person responsible for maintaining it. Ask the owner to walk through one recent contract change to test whether the register followed it.
Compare documents with system behavior
A complete document set can still fail if the documents describe controls the systems do not run. Sample a few policies, such as access control, backup, logging and change management, and trace each stated requirement to a configuration, a log, a ticket or a test result. Record every gap as a finding with an owner and a date. Supervisors often ask for proof of operation, not only the existence of a written rule, so this check should happen before any request.
Who writes, approves and checks the DORA documents
The financial entity owns every DORA document. The management body approves the core framework and policies, and it remains personally accountable for them, whatever help the organization uses to draft them. Operational owners such as the CISO, the head of ICT operations and the business continuity lead maintain their sections and keep them matched to how the systems actually run. The organization also runs the reviews that keep the set current.
- Approval by the management body: The ICT security policies must state the date the management body formally approved them, and the policy must be reviewed at least once a year.
- Named accountability: The ICT risk management policy must name the role or senior manager responsible for monitoring the arrangements.
- Operational ownership: Named owners maintain incident, continuity, backup and third-party documents and record exceptions.
- Annual and event-driven reviews: Reviews run on a set calendar and after major incidents or significant changes.
- Retained records: The organization keeps the approved versions, approval dates, exception logs and review minutes ready for supervisors.
Check that each document has a named owner, an approval date from the management body, and a review date in the calendar.
An implementation partner such as DeployOpen can help the organization turn policy requirements into working systems and evidence. Work typically covers draft templates for the policy set, configuration of self-hosted platforms so they match the stated controls, and collection of the logs, inventories and test results that show the controls operate. The partner does not approve policies, decide risk acceptance, sign the register of information or issue any attestation. Those decisions stay with the organization and its management body.
- Templates: Drafts of policies and procedures that the organization reviews, edits and adopts.
- System alignment: Configuration of logging, access control, backup and monitoring so the platforms reflect the written policies.
- Evidence preparation: Structured exports, test records and runbooks that show each control in operation.
- Document set support: Cross-referencing between policies, the asset inventory and the continuity plans so they stay consistent.
- Clear boundary: The partner prepares material only. It does not approve, certify or represent the organization to a regulator as an authority.
Check that the scope document states which drafts the partner prepares, who approves them and that the partner has no approval or attestation role.
Supervision of DORA compliance sits with the national competent authority for each type of financial entity, and the ECB for significant credit institutions. Supervisors use their Article 50 powers to request documents and test compliance. DORA does not create a certification scheme, so no body certifies an entity as DORA compliant. An independent auditor may test controls for the organization's own assurance or for a client, but its report is an opinion for that purpose, not a DORA certificate.
- Supervisory review: Competent authorities can request the policies, registers and review reports and assess them against the regulation.
- No DORA certificate: No certification scheme exists, so any claim of certification should be questioned.
- Independent audit: Auditors with ICT expertise and independence test the framework and report findings to the organization.
- Threat-led testing attestation: The only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7).
- Scope of opinion: Any audit report covers the agreed scope and criteria only.
Check which authority supervises your entity, and ask any assessor to state in writing what its report covers and what it does not.
Frequently asked questions about DORA required documents
Does a small financial entity need every DORA policy?
Yes in principle, but the depth expected depends on proportionality. Article 4 of DORA requires the ICT risk management framework to be applied in proportion to the entity's size, risk profile, nature, scale and complexity of its services. Smaller entities may use the simplified ICT risk management regime in Chapter II, which trims some documentation, such as the shorter framework review report. Confirm with your competent authority which simplifications apply to your entity type, because the simplified regime depends on your classification. Expect every required policy topic to still be addressed, even if a short document covers several topics.
Can an implementation partner write the DORA policies for us?
An implementation partner can draft policies, procedures and registers, align them with your existing systems and collect the evidence that shows they operate. The organization still owns its controls and must adopt the documents as its own. The management body must approve the ICT security policies and record the approval date, and it remains accountable for the framework. Only an independent auditor or competent authority reviews and assesses compliance. Ask any partner to show how drafts will be validated by your risk, compliance and business owners before approval.
How long does it take to produce DORA documentation?
The duration depends on the number of systems and services in scope, how much documentation already exists, how many business owners must review each policy, and how many third-party arrangements need contract and register work. Clear scope and a current asset inventory shorten the work, while missing ownership and unclear critical functions lengthen it. No fixed timeline applies across entities. Ask for a phased plan in the written scope that separates policy drafting, evidence collection, management approval and the annual review cycle, since the Regulation requires policies to be reviewed at least yearly.
Do open-source or self-hosted tools change the DORA documents?
The tools change the evidence and the operating detail, but not the obligations. Self-hosted platforms run inside your own infrastructure, so your policies must cover their configuration, patching, backup, logging, access control and encryption, just as they would for commercial software. Open-source software still needs documented ownership, support arrangements and an assessment of whether it supports a critical or important function. If a vendor, foundation or community provides support for a component, record that dependency in the register of information and the ICT third-party risk strategy. Confirm the support and security update arrangements for each component with its maintainer or provider.
Who signs off the DORA policies and plans?
The management body approves the ICT security policies, the digital operational resilience strategy and the key plans, and it must record the date of formal approval. Under the ICT risk management RTS, the management body must also review the policy at least once a year and name the role or senior manager responsible for monitoring the arrangements. Operational owners, such as the chief information security officer or head of ICT, prepare and maintain the documents. Internal audit then tests whether the framework works as documented. Confirm the internal approval chain in your governance charter before drafting starts.
Which DORA documents drive the highest cost and effort?
The largest effort usually sits in the documents that depend on accurate data about your environment. The asset inventory, the register of information, the ICT business continuity plans with recovery objectives, and contracts with ICT providers all require input from several teams. Cost components include internal staff time for interviews and reviews, external drafting or advisory support, and tooling for records. Most of the spend is one-time for the first version, followed by recurring effort for annual reviews, updates after major changes and evidence collection. Ask any quote to separate drafting, evidence preparation and ongoing maintenance so you can compare the recurring element.
Can we write DORA documents ourselves without outside help?
Yes, a financial entity can prepare its own documents if it has staff who understand DORA, the RTS requirements and its own systems. The main risk is incomplete coverage, since the Regulation and its delegated regulations list many specific policy elements, and gaps are easy to miss without a checklist. Teams often use this list as a structure, draft each policy against the common elements it must contain, and then test the documents against real configurations and records. Outside help is most useful for gap analysis, technical evidence and a second review before approval. Decide early which parts you will own internally.
How DeployOpen fits into the documentation work
DeployOpen prepares the systems, configurations and evidence that the DORA policies describe, under a fixed-scope written agreement, and the financial entity keeps ownership of every policy, control and approval. In practice, that means the scope document should name which policies DeployOpen will align to technical settings (for example, the logging procedures, access control rules, backup configurations and vulnerability management workflow in Delegated Regulation (EU) 2024/1774), which documents it will draft as working versions, and which it will only review. The entity's management body still approves the ICT security policies, records the approval date, and reviews them at least once a year. Those decisions cannot be delegated to an implementation partner, and the scope should say so.
Before signing, ask the proposed partner to put three things in writing: the list of deliverables mapped to specific policy sections, the named role inside your organization that accepts each deliverable, and the evidence each system is expected to produce, such as log exports, access review records or backup restore results. Confirm how changes to a policy after handover will be handled, because the entity must keep its documentation current as its ICT services change. Also confirm who in your organization owns the register of information and the exit plans, since those depend on contract and procurement knowledge that a technical implementer does not hold.
DeployOpen does not issue audit reports, attestations or certifications. Competent authorities supervise DORA compliance, and the only authority-issued attestation the Regulation provides for is the one covering a threat-led penetration test under Article 26(7). An independent auditor, internal audit function or assessor reviews the framework and its evidence, and the entity's supervisor decides on compliance. Treat any partner that offers a DORA certificate or compliance report as a warning sign, and confirm with your supervisor which assessments they expect you to commission and how they will want the evidence presented.
How DeployOpen prepares DORA evidence for the audit
DeployOpen helps financial entities and their ICT providers turn DORA's policy and document requirements into a working, versioned set of documents backed by real system configuration. We prepare the systems and evidence inside your own infrastructure, while your organization owns the policies, approvals and controls, and an independent assessor reaches the conclusions.
How we scope
- Engagements are fixed-scope, with the document list, deliverables and timelines agreed in writing before work starts.
- We map which policies and plans apply to your entity type, your ICT services and any self-hosted platforms in use.
- The written scope names who approves each document, so management body sign-off is planned rather than discovered late.
How we build
- We draft policy and procedure templates that carry the common elements the RTS requires, for your review and adoption.
- We configure self-hosted open-source platforms in your own cloud, data center or air-gapped network to produce the logs, inventories and backups the documents describe.
- We run security and resilience testing where the agreed scope includes it, and record findings against the affected policies.
How we hand over
- You receive the documents, configuration records and evidence index in formats your compliance team can maintain.
- Each policy carries a version history, a review date and a record of the management body approval date.
- We walk your control owners through the evidence so they can answer an assessor's questions without us in the room.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Retainers can cover the annual policy reviews and updates to the register of information when ICT services change.
- Confirm with your auditor or competent authority which evidence format they expect before we agree the final deliverables.
