Article 21(2)(a) NIS2 risk analysis and security policies

What Article 21(2)(a) NIS2 requires from your policies and risk analysis

Article 21(2)(a) requires an entity in scope of NIS2 to have documented policies on risk analysis and information system security. Under Implementing Regulation (EU) 2024/2690, those policies must cover a security policy with objectives and management commitment, defined roles and authorities, a risk management framework, compliance monitoring and independent review. When a national competent authority asks to see your position, it expects a written set of documents that management has approved and that match how the organization actually runs. The risk this point addresses is twofold: security decisions made without a documented basis, and policies that exist on paper only and are never applied or updated.

The hard part is rarely writing the first version. It is ownership and upkeep. Someone must be accountable for each policy, and that person must keep it current as systems, suppliers and sectors change. The implementing regulation expects the security policy and the risk assessment and risk treatment plan to be reviewed at least annually by management, and the independent review must be carried out by people with audit competence outside the area they examine, or under alternative impartiality measures if size does not allow that. Ask who signs each document, where the approval record is kept, and how management review will be evidenced for the next inspection.

NIS2 creates no certificate of compliance. Your organization owns its policies, its risk decisions and the management review that approves them. An implementation partner can prepare the policy set, the risk assessment method, the review calendar and the evidence trail, but only the organization can adopt them, and only an independent auditor or the competent authority can assess them. Confirm with your national authority which documents it expects, and check the ENISA technical implementation guidance for examples of evidence before you scope the work.

Which systems, teams and suppliers the policies and risk analysis must cover

The policy set and the risk analysis must describe the same environment. Scope decisions about systems, sites, subsidiaries, providers and people determine what the policies govern and what the risk assessment must test, so each decision should be recorded before drafting begins.

Network and information systems in service scope

Start by listing the network and information systems the entity uses to deliver its covered services, including the production, corporate and supporting environments that a failure could affect. Record owners, data classes and dependencies for each system. Check that no system falls outside both the policy set and the risk register by default, because an omitted system is an unmanaged risk rather than an excluded one.

Business units and sites

Each business unit, office, data center and operational site that touches in-scope systems needs a named owner and a clear statement of which policies apply there. Local rules, such as site access procedures or local backup arrangements, should be documented as implementations of the central policy. Confirm that every site appears in the risk assessment, including remote and home-office access paths.

Group subsidiaries and shared services

Where a group operates through subsidiaries, decide whether the parent policy binds them directly or whether each entity adopts it. Shared IT services that run for several legal entities must be assessed once and mapped to each entity that depends on them. Ask counsel to confirm which entity is the covered entity under the applicable national law, since that determines who must answer to the supervisor.

Cloud and managed service providers

Providers that operate systems inside the entity's environment, such as cloud platforms, managed hosting or outsourced security monitoring, must appear in the risk analysis with their responsibilities split clearly from the entity's own. Record which policies the provider must follow, which controls it operates and how the entity receives evidence of them. A provider that holds administrative access to in-scope systems is a risk the entity must analyze, regardless of who signed the contract.

People who hold security roles

The policy set must name who is responsible, accountable and authorized for each security task, including the management body, the person leading security and the owners of key systems. Assign deputies for each role so decisions do not stop during absence. Confirm that the reviewers of risk assessments are outside the line of authority of the area they review, or document the alternative impartiality measures that apply to the entity's size.

Member State and sector rules

The national transposition law of the Member State where the entity is established, or where its services are provided, determines which authority supervises it and how the rules apply. Sector-specific laws can displace parts of NIS2 for certain entities. Confirm the applicable national law and sector rules before fixing the policy scope, and align the risk analysis with the sector rules that the entity must also meet.

How an assessor tests the security policy and risk analysis

This table sets out the questions an assessor is likely to ask about the Article 21(2)(a) policy and risk analysis, the approach they take, the evidence they request and the gaps they most often find. Read it as a preparation checklist: each row maps to a point in sections 1 and 2 of Implementing Regulation (EU) 2024/2690. ENISA's June 2025 guidance offers examples of evidence, but it does not set the test.

Test question	Test approach	Evidence requested	Common findings
Does a documented security policy exist, and does it set objectives?	Read the policy and check that security objectives are stated and measurable in principle, per points 1.1.1 and 1.1.2 of Annex section 1.	Approved policy document with version history, stated security objectives and the approval record.	Policy exists but objectives are generic statements with no link to the entity's services or risks.
Does the policy commit to resources and continual improvement?	Check for explicit management commitments on resources and improvement cycles, then compare them with budget and staffing records.	Policy sections on resourcing and improvement, plus budget or staffing decisions that match them.	Commitments appear in the text, but no funding or staffing decision supports them.
Does the policy list topic-specific policies and documentation retention periods?	Compare the policy's list against the topic-specific policies ENISA's June 2025 guidance identifies, and confirm retention periods are stated.	Index of topic-specific policies, each with an owner, and the retention schedule.	Topic policies are referred to but not written, or retention periods are missing.
Does management review the policy at least annually?	Check the review record for the management body's sign-off within the last twelve months, per point 1.1.2.	Minutes or approval records showing management body review dates and decisions taken.	Review is done by the security team alone, or the last recorded review is older than a year.
Are roles, responsibilities and authorities defined and assigned to named people?	Trace each security responsibility to a named role and check that the role holder has the authority to act.	Role descriptions, a responsibilities matrix, and delegation or appointment letters.	Roles are named in the policy, but no person is appointed, or authority to stop or change systems is unclear.
Are risk assessments performed, documented and reviewed at planned intervals and at least annually?	Sample the risk register, confirm the method is written down, and check review dates against points 2.1.1 and 2.1.4.	Risk assessment reports, the assessment method, and records showing the latest review date.	Risk assessment was done once for a project, with no evidence of periodic review.
Is there a risk treatment plan that links each treated risk to an owner and a decision?	Pick several high-rated risks and follow each to a treatment decision, an owner and a status.	Risk treatment plan with accepted, mitigated, transferred or avoided decisions, and owner sign-off.	Risks are rated, but treatment actions have no owner, due step or residual risk decision.
Is there a risk management framework that explains how risks are identified, rated and accepted?	Check that the framework defines the rating scale, risk acceptance authority and escalation path, and that practice follows it.	Framework document, risk criteria, and examples of risk acceptance signed by the authority named in it.	Framework exists on paper, but ratings in the register were set using a different scale.
Is compliance with the policies monitored, and are independent reviews carried out?	Ask who checks policy compliance, how often, and whether reviewers sit outside the area they examine, per point 2.3.2. Where size prevents full separation, check for documented alternative impartiality measures.	Monitoring schedule, audit or review reports, reviewer competence records, and reporting lines showing independence or the alternative measures used.	Reviews are performed by the team that runs the controls, with no impartiality measures written down.

What the security policy and topic-specific policies must contain

The top-level security policy is the document that anchors everything else. Implementing Regulation (EU) 2024/2690 expects it to set security objectives, commit management to providing resources and to continual improvement, and list the topic-specific policies and the retention periods for documentation. Management bodies must review it at least annually. In practice, the policy should name the objectives in measurable terms (for example, which risk treatment decisions it sets and which metrics feed the annual review), state who approves it, and point to the register where each subordinate policy lives. Confirm the exact annex wording with the regulation itself before drafting, since the obligations are detailed there.

ENISA's June 2025 guidance identifies ten topic-specific policies that must be documented. They cover risk management, incident handling, supply chain security, security testing, cryptography and access control, and also include secure development and maintenance, human resources, asset management, business continuity and the use of multi-factor and secured communications. Each policy maps to one or more Article 21(2) measures, so the mapping itself is useful evidence. A supervisor who asks how the incident handling measure is governed should be able to open one policy, see its owner, and follow it to the procedures that implement it. Build that cross-reference once and keep it current.

Every policy needs a named owner, a scheduled review date and a version history. The owner is accountable for accuracy and for the decisions the policy records, and the review date proves the document is maintained rather than written once. Version history shows what changed, when and why, which matters when an incident or audit asks what the rule was at a given date. Ask whether your current document tooling records these fields automatically. Wiki platforms such as XWiki keep page-level version history with comparison and rollback, and CISO Assistant can hold policy records against the NIS2 framework, but confirm each feature in your own environment before relying on it.

How to build the policy set and risk analysis in sequence

This sequence takes an entity from an unclear scope to a approved, reviewed set of security policies and a documented risk picture that the other Article 21 measures can build on. Each step produces a named output that the next step needs.

Confirm scope and entity classification
Start by establishing which legal entities, sectors and systems fall under NIS2, and whether the entity is classified as essential or important. Legal or compliance staff confirm the sector annex and size position, and the CISO confirms which networks, information systems and services are in the boundary. The output is a written scope statement that names the in-scope entities, the classification and the systems covered. Every later document refers back to it, so it must be approved before risk work begins.
Assign roles, responsibilities and authorities
Name the people who own each part of the security program, including the policy owner, the risk owner for each business area, the incident coordinator and the person who reports to the management body. Record the authority each role holds, such as the power to accept risk or approve exceptions. The output is a roles and responsibilities register that the management body can read in one sitting. Confirm that no one reviews work they produced, since the independent review step depends on this separation.
Set the risk management framework and methodology
Choose the method the entity will use to identify threats, score likelihood and impact, set risk acceptance criteria and define the risk levels that trigger treatment. The implementing regulation expects a documented framework, so the choice must be written, not implied by a tool setting. The output is a methodology document with scoring scales, criteria and the owner of the method. Confirm the method with the risk owners before scoring anything, so the results are comparable across business areas.
Perform and document the risk assessment
Apply the methodology to the in-scope assets, processes and services, recording the threats, vulnerabilities, existing controls and resulting risk level for each. Use asset inventories, architecture diagrams, incident history and threat information as inputs, and keep the working papers with the results. The output is a dated risk register that shows how each rating was reached. The register is the basis for the risk treatment plan, and its assumptions feed the business continuity and supply chain work described under Article 21(2)(c) and Article 21(2)(d).
Write the risk treatment plan
For each risk above the acceptance criteria, decide whether to reduce, transfer, avoid or accept it, and name the measure, owner and target state. Record any risk accepted by management with its justification and the approver. The output is a risk treatment plan linked line by line to the risk register. Items in the plan usually become the requirements that the technical measures in Article 21(2)(e) through (j) must deliver, so check that each treatment has a named control or a documented reason it does not.
Draft the security policy and topic-specific policies
Write the top-level security policy, which states security objectives, commits to continual improvement and resources, and lists the topic-specific policies and documentation retention periods. Then draft the topic-specific policies that the implementing regulation requires, such as those for risk management, incident handling, supply chain security, security testing, cryptography and access control, using ENISA's June 2025 guidance as a checklist. The output is a versioned policy set with owners and cross-references to the risk register. Mapping each policy to the risk treatment items shows the reviewer why each policy exists.
Obtain management approval
Present the policy set, risk register and treatment plan to the management body, which must approve and oversee the Article 21 measures under the governance requirements of Article 20. Record the approval date, the names of approvers and any conditions or risks accepted at that meeting. The output is signed or minuted approval held in the document system with the version number. Keep the minutes, because a supervisor will ask for evidence that management was informed and took decisions, not only that a policy exists.
Set the compliance monitoring and independent review schedule
Define how compliance with the policies will be monitored, which metrics are reported to management and how often the risk assessment and treatment plan are reviewed. The implementing regulation requires review at planned intervals and at least annually, and independent reviews by people with audit competence outside the line of authority of the area reviewed, or under alternative impartiality measures where size does not allow this. The output is a dated review calendar with named reviewers. Ask any independent reviewer, internal or external, to confirm in writing that they meet the impartiality requirement.
Run the first review cycle
Test the policy set against the actual environment: sample a few controls, check that owners know their roles, confirm that the risk register reflects recent changes, and verify that the treatment plan is being executed. Record findings, assign corrective actions and feed the results back into the risk register and policy versions. The output is a first review report with a corrective action list and a version history. This closed loop is the evidence that the policy set works in practice, and it becomes the starting point for the effectiveness measures in Article 21(2)(f).

Evidence that satisfies the policy and risk analysis requirements

Article 21(2)(a) is tested through dated records, not through the existence of a policy document alone. The six artifacts below are what a national competent authority or an assessor will ask to see, and each one must show who approved it, when it was last reviewed and what changed since the last cycle.

Approved security policy with version history

The top-level information system security policy must set security objectives, commit to continual improvement and resources, and name the topic-specific policies that sit beneath it. Keep every approved version with its approval date, approver and a summary of changes, so the assessor can see that the policy was actually revised. Check that the document in use matches the latest approved version and that retired versions are retained for the documented retention period. A version history that records who approved each change and when is stronger evidence than a single current copy.

Topic-specific policy set with owners

The implementing regulation requires a set of topic-specific policies, and ENISA's June 2025 guidance lists ten of them, including risk management, incident handling, supply chain security, security testing, cryptography and access control. Maintain a register that gives each policy an owner, a version, a last review date and a next review date. Gaps show up quickly in this register, so check that every required topic has a policy and that none has a review date that has passed without a recorded review.

Risk assessment record and treatment plan

Risk assessments must be performed and documented, and the entity must keep a risk treatment plan that follows from them. The assessor expects a dated risk register showing threats, asset scope, likelihood, impact, the chosen treatment and the named owner of each residual risk. Reviews must happen at planned intervals and at least annually, so each review should leave a new dated entry rather than overwrite the old one. Ask whether the register can show how a risk moved between review cycles.

Management body minutes and approvals

The management body must review the security policy at least annually. Minutes or signed resolutions are the record that shows this happened, so keep the agenda item, the attendees, the document reviewed and the decision taken. A minute that says the policy was noted without a decision gives an assessor little to rely on. Confirm with counsel how your national transposition law defines the management body and its approval powers, since these vary by Member State.

Role and authority register

The implementing regulation asks for defined roles, responsibilities and authorities for security. Maintain a register that names each role holder, the decisions they may take, the reporting line and any deputy. Update it on every staffing change, and keep the prior versions so an assessor can match an incident or approval to the person who held the role at that date. Where a role is outsourced, such as a managed security provider or a vCISO, record the boundary of their authority in writing.

Independent review report and reviewer competence

Independent reviews must be carried out by people with audit competence who sit outside the line of authority of the area being reviewed. Where the organization is too small to meet that separation, it must apply alternative impartiality measures and record them. The report should state the scope, the reviewer's qualifications or the impartiality measures, the findings and the management response with due dates. Keep the reviewer's competence record with the report, because an assessor will ask how independence was established.

Self-hosted open-source tools that produce and hold this evidence

CISO Assistant is a governance, risk and compliance platform released under AGPL-3.0-only. It is the tool most directly tied to the framework side of Article 21(2)(a), because it holds the NIS2 framework alongside other frameworks and records assessments against them. It is useful for tracking the policy set, the risk register and the compliance status of each requirement in one place.

Framework library: The project states that it ships more than 200 frameworks, including NIS2, so you can start from a NIS2 structure instead of building the requirement list yourself.
Assessments and audits: It runs compliance assessments and audits against loaded frameworks, which gives you dated records of what was assessed and by whom.
Cross-framework mapping: It maps between frameworks automatically. Treat these mappings as the tool's configuration, and verify them against the ENISA guidance before presenting them to a supervisor.
Risk and policy records: Use it to link the risk assessment, risk treatment plan and policy documents to the requirements they support.

What it does not do on its own: it does not write your security policy, perform your risk analysis or decide your risk treatment. Management still approves the policies. Confirm the AGPL-3.0-only license terms with your legal team, because modifying and offering the software as a network service can trigger source-sharing obligations. Confirm the framework content, mappings and feature set in your own instance before relying on them.

What meeting Article 21(2)(a) costs in money and effort

This table compares the main cost and effort components of writing, approving and maintaining NIS2 security policies and risk documentation, and shows which are one-time and which recur. Amounts are not stated because no researched figures apply; read each row for who is paid, what drives the cost, and what to ask for in a written quote.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal time to write and approve the security policy and topic-specific policies	One-time, then updated	Number of topic-specific policies in scope, legal review, management body approval cycles	Reuse existing policies, agree a template early, and assign one accountable owner per policy
Risk assessment workshops with system and business owners	One-time, then repeated	Number of sites, systems and business processes, and how many people must attend	Prepare asset inventories before workshops and limit sessions to named owners
Risk treatment plan and management sign-off	One-time, then repeated	Number of risks accepted, mitigated or transferred and the depth of justification	Record decisions in a standard format so each cycle updates rather than restarts the plan
Tooling and licenses	Recurring if commercial, one-time for setup	Choice of platform, user count, hosting model and integrations with existing systems	Self-hosted open-source tools remove license fees for the platform, but staff time for setup, hosting and upkeep remains
Hosting and infrastructure for self-hosted tools	Recurring	Hosting location, backup and access requirements, and uptime expectations	Confirm hosting needs in the written scope and reuse existing infrastructure where the client's policy allows
Annual policy review and risk reassessment	Recurring	Frequency set by the implementing regulation (at least annually for policies and for risk assessments and treatment plans), volume of change in the environment	Schedule reviews against a fixed calendar and trigger extra reviews only on material change
External consultant or implementation partner support	One-time, sometimes recurring retainer	Maturity of existing documentation, team capacity, and the fixed scope agreed in writing	Ask for a fixed-scope quote with named deliverables and state which tasks stay in-house
Independent reviewer time	Recurring, at least periodic	Organization size, whether reviewers must sit outside the area reviewed, and the scope of the review	Use internal staff outside the reviewed line where size allows, or agree alternative impartiality measures and document them

Who owns the policies, who prepares the evidence and who assesses them

Your organization owns the Article 21(2)(a) program in law and in practice. The management body must approve the security policy, oversee its implementation and make the risk decisions that the policy produces, including which risks to accept, mitigate or transfer. A partner can propose options, but a named person inside the entity has to take and record the decision.

Management body approval: Management approves the security policy and reviews it at least annually, and the minutes should show that the review happened and what was decided.
Policy ownership: A named owner, often the CISO or security lead, keeps each topic-specific policy current and accountable for its implementation.
Risk decisions: Management accepts or rejects the risk treatment plan, sets risk appetite and assigns owners for each treatment action.
Records and retention: Your team keeps the signed approvals, risk registers, review records and the retention periods the policy sets.
Roles and authorities: Your team assigns the security responsibilities that the policy describes and confirms that people hold the authority to carry them out.

Before engaging anyone, confirm which of these decisions your management body will take personally and how it will document them.

Where organizations fall short on policies and risk analysis, and how to close each gap

Most Article 21(2)(a) findings come from documents that exist but do not work as a connected system. The gaps below share a root cause: policies, risk records and review evidence are not linked to approval, ownership and dates. Each card names the closing action and the evidence an assessor or supervisor would look for.

Policies never approved by management

Policies are drafted by the security team and published without a record that the management body reviewed and approved them. Implementing Regulation 2024/2690 expects management bodies to review the security policy at least annually, so an unsigned policy is hard to defend. Check for dated approval minutes or a signed approval record for each policy version, and confirm the approver is the management body rather than a department head.

Risk assessments disconnected from treatment

Risks are identified in a register that never feeds the risk treatment plan, so accepted, mitigated and transferred risks have no traceable owner or deadline. The regulation requires documented risk assessments and a risk treatment plan, reviewed at planned intervals and at least annually. Close the gap by giving every risk register entry a treatment decision, a linked action and a status, and by checking that each open action traces back to a risk.

Missing review dates and version history

Policies carry no next review date, no version number and no record of what changed. When an assessor asks what the policy said last year, the organization cannot answer. Add a document owner, an approval date, a next review date and a change log to every policy page. Version control in the wiki or document system should show what changed, when and by whom.

Roles defined without named people

The policy lists a CISO, a risk owner or a security committee, but no individual holds the role or has written authority. The regulation asks for roles, responsibilities and authorities, so a title alone is a gap. Name a person for each role, record their authority in the policy, and confirm the deputy or backup for each role so that continuity does not depend on one employee.

Independent review run by the control owner

The team that operates a control also audits it, so the review is not independent. Point 2.3.2 of the Annex expects reviews by people with audit competence outside the line of authority of the area reviewed, or alternative impartiality measures where size does not permit a separate team. Assign reviewers from outside the operating team, or document the impartiality measure and why it applies to your size.

Policies missing topic-specific references

The top-level policy states intent but does not list the topic-specific policies it depends on, such as incident handling, cryptography, access control and security testing. ENISA's June 2025 guidance identifies ten topic-specific policies the regulation requires to be documented. Build a policy index that lists each topic policy, its owner, its review date and where it is stored, and check that the top-level policy references that index.

Questions buyers ask about Article 21(2)(a) cost, effort and outsourcing

How long does it take to write NIS2 security policies and risk analysis?

No duration for this work is supplied in our research, so confirm the timeline in writing with any partner before you commit. The effort depends on how many policies you already have, how many systems and business units fall within scope, how many topic-specific policies the implementing regulation requires you to document, and how quickly management can review and approve drafts. An organization with a current risk register and mature policies needs far less time than one starting from nothing. Ask for the timeline in the scope document, with milestones tied to the deliverables and the management approvals they depend on.

Can our own team prepare the Article 21(2)(a) policy set without an outside partner?

Yes, an organization can prepare the policy set and risk documentation with its own staff, because NIS2 does not require a consultant. The harder part is consistency: the security policy, risk assessment, risk treatment plan and topic-specific policies must agree with each other and with what your systems actually do. Internal teams often underestimate the time needed to collect evidence and to keep the documents current at the planned review intervals. An outside partner can prepare systems, document controls and evidence formats, but your organization must own the policies and the decisions they record.

What does management and staff time look like for this work?

Management has to approve the security policy, set security objectives, commit resources and review the policy at least annually, so those approvals are non-delegable work for senior leadership. Risk owners must confirm the assets, threats and treatment decisions in their areas. System owners and IT staff provide the technical facts that the documents describe. Plan for workshops where people agree on scope and risk criteria, followed by review cycles in which drafts are corrected. Ask any partner to list which roles it needs, how many hours it expects from each, and which decisions it cannot make on your behalf.

Does NIS2 issue a certificate once our policies are in place?

No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Your policies and risk documentation are evidence you present to those authorities, not a credential you receive. Some organizations also pursue voluntary standards such as ISO/IEC 27001, which do issue certificates from accredited certification bodies. Check with your national authority how it expects evidence to be presented, since supervisory practice varies by Member State.

What must an independent review of the security policies look like?

The implementing regulation requires independent reviews of the risk management framework, compliance monitoring and related measures to be carried out by people with audit competence who sit outside the line of authority of the area being reviewed. Where your size does not allow full separation, you must apply alternative impartiality measures and be able to explain them. The reviewer does not have to be an external firm, but must be demonstrably independent and competent. Ask any provider to state how it will ensure independence if it is also helping you build the controls it later reviews.

Can one policy set cover all entities in a corporate group?

A shared policy set can work across a group, provided it covers each in-scope entity's actual systems, risks, roles and reporting lines. Each entity remains responsible for its own obligations, so group documents should state which entity owns which risk and where local annexes or exceptions apply. Groups operating in several Member States also need to check how each national transposition law applies to each entity. Confirm the approach with your legal advisers and the competent authorities in each relevant country before you rely on a single document set.

What should a written quote for this work include?

A quote should follow from a written scope that names the deliverables, the systems and entities covered, and the responsibilities of each party. Ask for the list of policies to be produced, the risk assessment method and the review cycle, along with the evidence formats the work will create. Confirm what is one-time work, such as the initial policy set and risk assessment, and what recurs, such as annual reviews and updates after major changes. Require an explicit statement of what the partner will not do, including signing off on compliance or issuing any report, because only an independent auditor or authority can do that.

How DeployOpen prepares your policies, risk analysis and evidence

DeployOpen plans and implements the self-hosted open-source platforms that hold your policy library, risk register, treatment plan and review records, inside your own infrastructure. We prepare the systems and documented evidence for Article 21(2)(a) so your management body can approve and oversee them, while your organization keeps ownership of every policy and decision.

How we scope

Each engagement starts with a written scope that names the policies, entities and systems covered by Article 21(2)(a).
Scope documents which of the ten topic-specific policies in the implementing regulation your organization must maintain, and which owner signs each one.
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins, and a quote follows from that scope.

How we build

We set up the document management and compliance platforms in your cloud accounts, data centers or air-gapped network.
We configure version history, role-based permissions and an approval workflow so each policy change is traceable to a named author.
We structure the risk assessment and risk treatment plan records so reviews at planned intervals and at least annually leave a clear audit trail.

How we hand over

We deliver the populated policy set, role descriptions and risk documentation in the platforms your staff will maintain.
We document how each record is produced, reviewed and retained, so your team can show a supervisor how the evidence was made.
We walk through the review cycle with your management body and independent reviewers, who must sit outside the area they examine.

How we support

Ongoing support, upgrades and maintenance of the platforms are available as a retainer after handover.
Retainers can cover annual policy reviews, updates for changes to the implementing regulation guidance and periodic evidence checks.
Independent audit, assessment or certification remains the role of an external assessor, and DeployOpen does not issue reports or certificates.