How do you run the NIS2 risk assessment, and how often must it be repeated?
An in-scope entity must document its risk assessment, cover all hazards, and review it at planned intervals and at least annually under Implementing Regulation (EU) 2024/2690. If a customer or national authority asks for proof, the answer is a dated, written assessment with a risk treatment plan, not a verbal description of how the team thinks about risk. The all-hazards scope matters as much as the cyber scope. Recital 79 of NIS2 gives examples such as theft, fire, flood, telecommunication or power failures and unauthorized physical access, so an assessment that only models attackers on the network will not satisfy the requirement. The scope, the number of assets and the proportionality decisions change the answer for each organization. Article 21(1) ties the measures to risk exposure, entity size, the likelihood and severity of incidents, and their societal and economic impact, and it asks that they reflect the state of the art and implementation cost. Two organizations of similar size can therefore produce different assessments and both be defensible, provided each records why it chose its scope, its criteria and its treatment decisions. Confirm with your national competent authority or sector guidance whether it expects a particular method, since the Implementing Regulation sets requirements for outcomes rather than a single named technique.
In practice, start by confirming which assets fall inside the assessment boundary and classifying each one. Point 12.1 of the Annex to the Implementing Regulation requires a classification level based on confidentiality, integrity, authenticity and availability, with availability aligned to continuity recovery objectives. Those classifications feed the business impact analysis required by point 4.1.3, and the results decide which risks rank highest and which treatment measures come first. Record who accepts the residual risk. Under point 2.1.1, the management body or an accountable person with authority to manage risk must accept the results, and the entity must ensure adequate reporting to that body. Plan the annual review now, with a named owner, a date and a change trigger such as a major incident, a new supplier or a significant system change, so the evidence stays current when a supervisor asks for it.
How the assessment is performed step by step
The sequence turns scope into a documented risk picture, a treatment plan and an accepted residual risk that management can stand behind. Each step closes with a record you can show a supervisor.
Define scope and the systems in it
Name the entity, the services it provides and the network and information systems that support them, including cloud tenancies, data center sites, remote access paths and systems run by suppliers. The owner is usually the CISO or head of IT, with business leads confirming which services matter. The step is done when a scope statement lists every system and boundary the assessment covers, and the exclusions are written down with a reason.
Classify assets by security requirements
Assign each asset a classification level based on the confidentiality, integrity, authenticity and availability it needs. Set availability requirements with the business continuity recovery objectives in mind, since the implementing regulation links the two. The output is an asset register with a classification field for each item and a named owner. Ask your team to show how a sample of assets was classified and who approved the level.
Identify threats across all hazards
List the threats that could affect each in-scope asset, covering cyber attacks and also non-cyber events such as theft, fire, flood, power or telecommunication failure and unauthorized physical access. Pair each threat with the vulnerabilities that would let it cause harm, drawing on vulnerability scans, penetration test results, incident history and supplier information. The output is a threat and vulnerability register linked to the asset register.
Estimate likelihood and impact
For each threat and vulnerability pair, estimate how likely the event is and how severe the impact would be on the service, the entity, its users and wider society. Record the basis for each estimate, such as incident data, threat intelligence, or expert judgment, so a reviewer can challenge it. Common methods such as those in ISO/IEC 27005 style approaches are widely used, but you choose one you can document and apply consistently. The output is a scored risk list with the rationale attached.
Evaluate risks against acceptance criteria
Compare each scored risk with the criteria management has set for what it will tolerate. Risks above the line go to treatment, and risks below it may be accepted with a documented decision. The criteria themselves should be approved by the management body or an accountable person with authority over risk. The output is a prioritized list showing which risks need treatment and which are already within tolerance.
Produce the risk treatment plan
For each risk requiring treatment, record the chosen option (reduce, avoid, transfer or accept), the measures selected from the Article 21 areas, the owner, and the target status. Link each measure to the business continuity requirements from the business impact analysis so recovery targets are reflected. The plan is reviewed at planned intervals and at least annually. The output is a treatment plan that a supervisor could trace from a single risk to a specific control.
Record residual risk and management acceptance
After treatment, estimate the residual risk that remains for each item and document it. Present the results to the management body, or to an accountable person with authority to manage risk, with enough detail for an informed decision. Confirm that the reporting path is recorded and that the acceptance is signed or minuted. Confirm with your own governance rules who may accept each residual level. The output is a signed residual risk register with the acceptance decision and date.
How asset classification drives the measures
Risk assessment only works if the organization knows what it is protecting and how much each system matters. Asset classification and the business impact analysis turn that knowledge into levels that set the depth of each Article 21 measure and the recovery targets behind continuity planning. The cards below follow that chain from inventory to continuity requirements.
Build a complete asset inventory
Start with a register of every network and information system in scope, including cloud tenants, SaaS services, endpoints, OT components and the people and suppliers who administer them. Record owner, location, hosting model and the business service each asset supports. Ask whether the register is generated from discovery tools or maintained by hand, because gaps in the inventory become gaps in the assessment. Confirm that shadow systems and supplier-operated assets are included.
Classify each asset on four properties
Point 12.1 of the implementing regulation requires every asset to carry a classification level based on confidentiality, integrity, authenticity and availability requirements. Record a level for each property separately, not a single label, because a system can be sensitive to disclosure yet tolerant of short outages. Document the criteria behind each level so an assessor can reproduce the decision. Review levels when the data, users or dependencies change.
Run the business impact analysis
Point 4.1.3 requires entities to carry out a business impact analysis and derive continuity requirements for network and information systems from it. For each business service, record the consequences of disruption over time, the processes and assets it depends on, and the tolerable loss of data and service. Involve business owners, not only IT, because they hold the knowledge of impact. Keep the analysis tied to the asset register so each dependency is traceable.
Set recovery objectives from impact
Availability classification must align with business continuity recovery objectives. Translate the impact analysis into a recovery time objective and a recovery point objective for each critical service, and record who approved them. Check that backup frequency, failover design and restore testing can meet those targets, since a stated objective that no control can achieve will not survive supervisory questioning. Record the gap between target and current capability as a risk to be treated.
Let classes set measure depth
The classification level should decide how strongly each Article 21 measure applies to an asset. Document the rule set, for example which levels require stronger access control, encryption, logging retention or supplier review. Record any asset where the default rule was overridden and why. A proportionate program should show that higher-classified assets receive more controls, which is the link assessors look for between the risk assessment and the measures in place.
Review classes and impact at least annually
Risk assessments and treatment plans must be reviewed at planned intervals and at least annually, so classification and impact analysis belong in the same cycle. Trigger earlier reviews after major system changes, new suppliers, mergers or a significant incident. Keep dated versions of the register and the impact analysis so the history of decisions is visible. Ask who signs off the review, because management must be informed of the results.
Including suppliers and critical supply chains in the assessment
Article 21(3) of NIS2 requires that the risk assessment take account of each direct supplier's specific vulnerabilities, the overall quality of suppliers' products and cybersecurity practices (including secure development), and the results of EU coordinated risk assessments of critical supply chains under Article 22(1). For the assessment, this means supplier risk is not a side document. A direct supplier that hosts, operates or changes your network and information systems is a source of risk, and it belongs in the same asset and threat analysis as your own systems. Start with an inventory of direct suppliers that touch in-scope systems, then record for each one what it provides, which assets it can affect and what would happen if it failed or was compromised.
Supplier risks enter the same risk register and the same risk treatment plan as every other risk. Each entry should carry an owner, a likelihood and impact rating, the treatment chosen (for example, a contractual requirement, a compensating control on your side, or an accepted residual risk), and a review date. The management body or accountable person who accepts residual risk should see supplier entries explicitly, not buried in a general category. Confirm with your legal and procurement teams which supplier evidence you can obtain contractually before you set treatments, such as security attestations, vulnerability disclosure commitments, incident notification timelines, audit or information rights, and access to secure development documentation. Where a supplier will not provide evidence, record that as a risk in its own right.
Two inputs are easy to overlook. The first is the EU coordinated risk assessments of critical supply chains that Article 22(1) provides for. Check whether any of them covers the technologies or suppliers you rely on, and record how you considered the results. The second is the quality of supplier products and practices, which you should judge against evidence rather than assumptions, and revisit at the planned review intervals and at least annually, as the risk assessment itself requires. Whether your organization or a specialist advisor performs this supplier analysis, the decisions remain yours to document and approve.
Who accepts residual risk and when the assessment is reviewed
Risk acceptance and review are where a NIS2 risk assessment becomes a management decision rather than a technical exercise. The cards below cover who signs off on residual risk, how reporting reaches the management body, the annual review cycle, and the events that should trigger a review between scheduled cycles.
Who accepts residual risk
Under Implementing Regulation 2024/2690, residual risk is accepted by the management body or by accountable persons who have authority to manage risks. Confirm in writing who holds that authority in your entity, whether it is the board, a committee or a named executive, and record the decision with its date and scope. Delegation is possible, but the entity must still ensure adequate reporting to the management body.
Reporting that enables real decisions
Management cannot accept risk it does not understand. Prepare a short summary for each cycle that lists the top risks, their assessed likelihood and impact, the chosen treatment, and the residual risk left after treatment. Note which risks exceed the entity's stated tolerance and which were accepted despite that. Keep the full register available as an annex so the decision can be traced back to its evidence.
Planned intervals and annual review
The assessment and the treatment plan must be reviewed at planned intervals and at least once a year. Fix the review date in the governance calendar, assign an owner, and link it to the information system security policy review so the two cycles do not drift apart. A missed review is a common supervisory finding, so keep meeting minutes and the approved version of the register as proof that the cycle ran.
Feeding effectiveness results into treatment
Measures that do not work should change the treatment plan. Track results from control tests, monitoring metrics, exercises and incident reviews against each risk treatment. When a measure underperforms, record whether the fix is a new control, a reconfigured tool or an accepted residual risk. Tie each change back to the risk entry so a supervisor can see the chain from result to decision.
Independent review results in management reporting
Management reporting should include the findings of independent reviews, such as internal audit, external assessments or penetration tests, alongside the risk register. Ask who performed each review, what scope it covered, and which findings remain open. Open findings that touch high residual risks should appear in the same management paper as the risk decision, so the board is not accepting risk without knowing the audit position.
Triggers for out-of-cycle review
Scheduled reviews will not catch everything. As a matter of practice, reassess the affected risks after a major incident, a significant change to network or information systems, a new cloud or supplier dependency, an acquisition or reorganization, or a published vulnerability that affects a critical asset. Record the trigger, the scope of the reassessment and the outcome, and report the result to the same people who accept residual risk.
What documentation a supervisor will expect to see
This table lists the records a competent authority is likely to ask for when it tests a NIS2 risk assessment, with the purpose, owner and evidence for each. Read it as a checklist: if any artifact is missing or undated, the assessment is harder to defend. Retention periods and exact formats should be confirmed with your national authority.
| Artifact | Purpose and owner | How it is evidenced |
|---|---|---|
| Risk methodology | Defines how risks are identified, scored and compared, and how proportionality factors were applied. Owned by the security lead, approved by management. | Dated, versioned document showing scales, likelihood and impact criteria, and the all-hazards scope |
| Asset register with classification | Lists network and information systems and classifies each by confidentiality, integrity, authenticity and availability. Owned by IT operations with security review. | Exported register with a classification level per asset and the date of the last review |
| Risk register | Records each identified risk, its score, its owner and its link to affected assets. Owned by the risk owner for each system or process. | Current register with scores, owners, dates of assessment and change history |
| Risk treatment plan | Sets out which measures address each risk, who delivers them and by when. Owned by the security lead, tracked by the accountable managers. | Plan with actions, deadlines, status and links to the Article 21 measures they support |
| Business impact analysis | Derives continuity requirements and recovery objectives for network and information systems. Owned by business continuity or operations. | Dated analysis showing impacts, dependencies and the recovery objectives used for availability classification |
| Management acceptance record | Shows that the management body or an accountable person accepted the assessment results and residual risks. Owned by the management body. | Signed or minuted approval naming the residual risks accepted and the reporting received |
| Review minutes with dates | Shows that the assessment and treatment plan were reviewed at planned intervals and at least annually. Owned by the security lead. | Dated meeting minutes, change records and a documented review schedule |
| Independent review results | Shows that the effectiveness of risk treatment measures was checked independently and reported to management. Owned by internal audit or an external reviewer. | Review report with findings, owner responses and the date it went to management |
Who owns the assessment and who can help
The organization owns the risk assessment in full. Under the requirements of Implementing Regulation (EU) 2024/2690, the results of the risk assessment and the residual risks must be accepted by the management body or by accountable persons who have authority to manage risks, and the entity must make sure those results are adequately reported to the management body. No consultant, tool vendor or provider can take that acceptance on the organization's behalf, and the management body remains accountable under Article 20 for approving and overseeing the Article 21 measures.
- Management acceptance: Decide who the accountable persons are, document their authority, and record their acceptance of the assessment results and each residual risk.
- Risk owners: Assign a named owner to every risk in the register, with authority to fund and direct its treatment.
- Asset owners: Confirm the classification of each asset for confidentiality, integrity, authenticity and availability, including the recovery objectives that feed the business impact analysis.
- Proportionality decisions: Record why measures are proportionate given exposure, size, incident likelihood and severity, and societal and economic impact.
- Final decisions: Approve the treatment plan, accept or reject residual risk, and decide when the assessment is reviewed again, at least annually.
Before relying on any outside help, confirm in writing which of these decisions your own management body will take and which named individuals will sign them.
An implementation partner such as DeployOpen can prepare the material the organization needs to make its decisions. The partner works inside the client's infrastructure and under a written, fixed scope, so the boundary between preparation and decision should be stated in that scope. DeployOpen prepares systems, controls and evidence for assessments. It does not issue audit reports, attestations or certifications, and it does not accept risk or decide treatment on the organization's behalf.
- Asset inventories: Build and reconcile the inventory of network and information systems, including cloud accounts, data centers and air-gapped segments, for the organization to classify.
- Assessment tooling: Set up a self-hosted register or GRC tool, configure the risk method the organization selects, and import the inventory and existing findings.
- Register setup: Structure risk entries, treatment plans, owners and review dates so that results can be reported to management in a consistent form.
- Evidence collection: Gather configuration exports, logs, backup records and access reviews that show the assessment inputs and the status of each treatment.
- Documentation support: Draft assessment records for the organization's review, keeping the reasoning visible so that decision-makers can challenge it.
Ask the partner to list every deliverable, state who approves each one, and confirm that no statement of compliance or certification is part of the scope.
Independent review and supervision come from outside the organization. Implementing Regulation (EU) 2024/2690 requires that the effectiveness results and independent review results are reported to management bodies, so an independent review is an expected input to the risk program. National competent authorities oversee compliance through inspections, security audits, security scans and information requests under Articles 32 to 34 of NIS2. NIS2 creates no certificate of compliance, so an assessor's report is evidence for management and supervisors, not a certificate.
- Independent review: Arrange for a reviewer who is not responsible for running the risk program to test the method, the inputs and the treatment decisions.
- Supervisory inspection: Expect a competent authority to ask for the assessment, treatment plan, acceptance records and review history, depending on the entity's classification.
- Security audits and scans: Be ready for authority-led testing of exposed systems, which will check whether the risks recorded in the register match what is found in practice.
- Information requests: Keep documents retrievable by date so that the assessment and its updates can be shown as they stood at a given time.
- Scope of the reviewer: Confirm whether the reviewer will test design, operating effectiveness, or both, and whether the report will be shared with the management body.
Confirm with your national competent authority which assessment records it expects and how it will request them.
Tools that hold the register and the evidence
A risk assessment is only as defensible as the records behind it. The register, asset inventory, treatment tracking and evidence store need to stay linked so that a supervisor can trace a risk from its source to the measure that treats it. The cards below describe the records to keep and what to check before choosing a tool to hold them.
Risk register with traceable entries
The register records each risk, its likelihood and impact ratings, the assets it touches, the scenario that drives it and the owner. Each entry should point to the Article 21 measure that treats it and to the date of the last review. Ask whether the tool lets you set rating scales yourself, since proportionality decisions depend on scales your organization can explain. Confirm whether custom fields and history are available in the edition you plan to run.
Asset inventory and classification
Point 12.1 of Implementing Regulation 2024/2690 expects every asset to carry a classification level based on confidentiality, integrity, authenticity and availability, with availability tied to recovery objectives. The inventory is the base for scoping the all-hazards assessment, so it should cover systems, data stores, suppliers and physical sites. Check whether the tool supports asset relationships and bulk import from your CMDB, because manual upkeep is where inventories drift.
Treatment plan and residual risk acceptance
The risk treatment plan lists each action, its owner, its target date and its status. Residual risk must be recorded with the name of the person who accepted it, and that acceptance must trace back to a management body or an accountable person with authority to manage the risk. Confirm that the tool keeps an approval trail for acceptance decisions, since a plan that cannot show who approved what will not satisfy a reviewer.
Evidence store and review cycle
Supervisors expect assessments and treatment plans to be reviewed at least annually, and the review records should be retrievable alongside the evidence that supports each measure. An evidence store links artifacts such as scan reports, backup restore logs and configuration exports to the risks they support. Confirm how the tool handles file storage, versioning and access control, and whether the review date reminders are configurable.
Self-hosted GRC platforms and their editions
CISO Assistant and eramba Community can hold registers, assets, treatments and evidence on infrastructure you control, which keeps risk data inside your own environment. The two products differ in licenses and in which features are reserved for paid editions, so the same register may not be available in both. Before choosing, confirm the license terms, the NIS2 content available and the features in the edition you will deploy. The GRC tools guide explains the trade-offs in more detail.
Questions buyers ask about the NIS2 risk assessment
Do small organizations need a NIS2 risk assessment?
Yes, if the organization is in scope. Size changes how much effort the assessment takes, not whether it is required. Article 21(1) ties proportionality to risk exposure, entity size, the likelihood and severity of incidents, and their societal and economic impact, so a small entity can run a lighter assessment with fewer assets and simpler treatment options. Whether NIS2 applies at all depends on sector, size thresholds and national law, which should be confirmed with the national competent authority or a legal adviser before any scoping work starts. Once in scope, the entity must still document the assessment, keep a treatment plan and review both at least annually.
How long does a NIS2 risk assessment take?
No fixed duration applies, and the effort depends on the drivers below. No supplied source sets a standard timeline, so ask any provider for a duration tied to a written scope. The main drivers are the number of systems and asset classes in scope, how many sites, cloud accounts and suppliers the assessment covers, whether asset inventories and business impact analyses already exist, and how many management and technical people must be interviewed. Organizations with current inventories and a recent continuity analysis usually move faster. Expect the first cycle to take longer than later annual reviews, which update an existing register rather than building one.
Does NIS2 require an outside consultant to run the risk assessment?
No. NIS2 does not require an external party to perform the risk assessment, and the organization owns the result. Many organizations still bring in outside help because the work needs knowledge of threats, asset classification, business continuity and the implementing regulation's method. An implementation partner can prepare the asset register, facilitate workshops, draft the treatment plan and organize evidence. Management still decides on risk acceptance. Any engagement should be fixed in writing, with the deliverables, owners and review dates listed, so internal staff know what they must keep after the partner leaves.
Does a successful risk assessment produce a NIS2 certificate?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. A risk assessment is evidence that the entity is managing risk as the directive requires, and supervisors will ask to see it along with the treatment plan and the decisions behind it. Certificates may exist for other frameworks such as ISO/IEC 27001, but they do not replace the NIS2 assessment or prove compliance with it. Only an independent auditor or certification body can issue a certificate under a standard that offers one.
How often must the NIS2 risk assessment be repeated?
The assessment and the risk treatment plan must be reviewed at planned intervals and at least annually, according to Implementing Regulation (EU) 2024/2690. Plan a full re-assessment when something material changes, such as a new system, a merger, a major supplier change, a significant incident or a shift in the threat picture. Between full cycles, the annual review checks that asset classifications, risk ratings and treatment owners are still correct. Record the date of each review, who attended, what changed and who accepted the residual risk, because supervisors will look for that history.
What must the management body sign off on for the risk assessment?
The management body or an accountable person with authority to manage risks must accept the risk assessment results and residual risks, provided the entity makes sure management receives adequate reporting. In practice, the sign-off record should include:
- The scope, method and date of the assessment
- The asset classifications and business impact results used
- The main risks, the treatment decisions and the residual risks being accepted
- The reporting provided to management and any independent review results
Under Article 20, the management body must also approve and oversee the Article 21 measures, so the sign-off should link the assessment to the measures it drives. Keep the signed record with the assessment so it can be produced during supervision.
Where risk assessments usually fail review
The most frequent failure is a risk assessment that records conclusions without the reasoning behind them. Article 21(1) ties the depth of measures to risk exposure, entity size, the likelihood and severity of incidents, and societal and economic impact, so an assessor will ask why a control was judged proportionate for one system and not another. The fix is a written proportionality note for each risk decision that names the factors considered, the evidence used and the result. Pair it with a dated list of the measures the entity judged disproportionate or unnecessary, because a blank rationale reads as an assessment that was never performed. Confirm the proportionality factors against Article 21 in the NIS2 text on EUR-Lex before you draft the template.
The second failure is a register with no asset classification. Point 12.1 of Implementing Regulation (EU) 2024/2690 requires every asset to carry a classification level based on confidentiality, integrity, authenticity and availability, with availability aligned to business continuity recovery objectives. Risks scored against unclassified assets cannot be compared, and the business impact analysis required under point 4.1.3 has nothing to draw from. Start with a short inventory that assigns each system a level on all four properties and links it to a recovery objective agreed with the business owner. Then check that every risk row names an asset from that inventory.
Two further failures are a register that never reaches management and residual risk that nobody has accepted. Point 2.1.1 requires results and residual risks to be accepted by the management body or by accountable persons with authority to manage risk, and to be reported to them adequately. In practice, a risk owner signs a spreadsheet that the board never sees, or the risks stay open with no named acceptor. Put the residual risk table on the agenda of a management meeting, record the decision, and name the person who accepts each residual risk. Finally, annual reviews fail when they carry no date or version. Point 2.1.4 expects planned reviews at least once a year, so record the review date, the approver and the change log on the document itself, and confirm the cycle with your competent authority's guidance or your legal counsel.
How DeployOpen prepares the assessment and its evidence
This sequence turns the organization's risk method into a documented assessment, treatment plan and evidence set that management can review and accept, while the organization keeps ownership of every risk decision. DeployOpen prepares the material and does not issue any report or certificate.
Agree the scope and method in writing
Before any work starts, DeployOpen and the organization agree in writing which systems, sites, suppliers and services fall within the risk assessment, which all-hazards threat categories are considered, and which deliverables will be handed over. The organization decides its risk method and proportionality factors, and DeployOpen confirms that the chosen method can produce the required records. The step closes when the signed scope document lists the in-scope systems and the deliverables.
Build the asset inventory and classification
DeployOpen compiles an inventory of in-scope network and information systems from the organization's own records and from discovery tooling run inside its environment. Each asset receives a classification level based on confidentiality, integrity, authenticity and availability requirements, with availability tied to the business continuity recovery objectives set by the organization. The inventory is complete when the organization's asset owners have reviewed each entry and confirmed the classification.
Prepare the risk register and business impact inputs
DeployOpen structures the risk register so each risk links to assets, threats, existing measures, likelihood and impact, and the proportionality factors applied. Where business impact analysis inputs are needed, DeployOpen gathers them from the business owners the organization names and records the continuity requirements they produce. The register is ready for review when every risk has an owner, a rating method and a traceable source.
Draft the risk treatment plan for approval
DeployOpen drafts the risk treatment plan, mapping each unacceptable risk to a treatment option, a responsible person, the Article 21 measure it supports and a review date set by the organization. Residual risks are shown separately so the decision-maker can see what remains. The organization, not DeployOpen, decides which treatments to adopt and which risks to accept. The draft is complete when the organization has marked each item approved, changed or rejected.
Route residual risk to accountable management
The organization presents the assessment results and residual risks to its management body or to the accountable persons with authority to manage risks, with a report that makes the reporting line explicit. DeployOpen can prepare the briefing material and the decision record, but acceptance is recorded by the organization's own management. The step closes when the acceptance record names who accepted each residual risk and when.
Compile the evidence files
DeployOpen gathers the evidence behind each risk and treatment entry, such as configuration exports, asset records, approval records and the outputs of any testing carried out under separate agreement, and stores them in an index that cross-references the register. Evidence is labeled with its source, date and owner. The package is ready when every register entry points to at least one evidence file the organization can produce on request.
Hand over the package and set the annual review
DeployOpen hands over the register, treatment plan, evidence index and asset inventory in the formats agreed in the scope document, and walks the organization's staff through how to update them. The organization schedules the review at planned intervals and at least annually, and assigns owners for each update. Any independent review of the assessment is carried out by a party the organization engages separately, and DeployOpen does not issue reports or certificates. The handover is complete when the organization confirms receipt and records the next review date.
