What the Cyber Resilience Act risk assessment must show
The Cyber Resilience Act requires a manufacturer to assess the cybersecurity risks of a product with digital elements before and throughout its life, and the documented outcome decides which Annex I Part I points apply. The assessment is the document every other Annex I decision traces back to. Article 13(2) asks the manufacturer to analyze cybersecurity risks and use the result during planning, design, development, production, delivery and maintenance, so that risks are reduced, incidents are prevented and their impact, including on user health and safety, is minimized. Article 13(3) adds the specifics: the assessment must be documented, updated as appropriate during the support period, and must analyze risks based on the intended purpose, reasonably foreseeable use and conditions of use of the product.
Article 13(3) also requires the assessment to state whether and how each point (2) requirement in Annex I Part I applies and is implemented. Article 13(4) places it in the technical documentation, with a clear justification wherever an essential requirement is judged not to apply. The regulation does not prescribe a methodology. Commission FAQ 4.1.2 says threat modeling should reflect the intended purpose, so a product used in critical infrastructure should be assessed against threats such as nation-state actors. Confirm the methodology you adopt with your notified body or market surveillance counterpart early, and record why you chose it.
Three problems make this assessment hard in practice. The first is scope creep, where the analysis drifts from the product as sold to every integration, customer deployment and future feature, so the boundary of the assessment is never fixed. The second is undocumented justifications: teams mark a point (2) requirement as not applicable without writing the reasoning, which leaves the technical file unable to defend the decision. The third is the missing owner after launch. The assessment must stay current through the support period, so someone with authority must own it, trigger reviews when the threat picture or product changes, and sign off each revision. Ask who holds that role before the first release, not after the first vulnerability report.
Which products, components and third parties the assessment covers
The risk assessment is only as good as its boundary. Before anyone scores a threat, the manufacturer has to decide what the product is for, how it will be used, what sits around it and which category it falls into. Each decision below changes which threats are in view and which Annex I points apply.
Intended purpose and foreseeable use
Article 13(3) requires the assessment to start from the product's intended purpose, its reasonably foreseeable use and its conditions of use. Write these down as statements the team can test, such as who the users are, what data they enter and where the product runs. Then ask what a careless or malicious user could realistically do with it. Each answer adds threats and can move a point (2) requirement from not applicable to required.
Conditions of use and environment
Deployment conditions change exposure. A product exposed to the internet, run on shared networks or installed by integrators in industrial sites faces different threats from the same code in a closed lab. Record network placement, physical access, administrator model and expected maintenance windows. Where conditions differ between customers, document each condition set separately rather than averaging them.
Connected services and cloud backends
A product that relies on a vendor-run cloud service, account system or remote update channel has an attack surface outside the device or application. Decide whether those services are part of the product for the assessment or are third-party services the product depends on. Either way, record the data flows, trust relationships and failure modes so that points (2)(d), (2)(h) and (2)(c) can be judged against the full picture.
Third-party and open-source components
Every library, firmware blob, container base image and licensed component inherits risks into the product. Build the component list from the build pipeline, not from memory, and note which components are open source and which are supplied under contract. Open-source components still count as part of the product for the assessment. Confirm how each one is maintained and who will ship its security fixes during the support period.
Default, important or critical category
The product's core functionality decides whether it is default, important (Annex III class I or II) or critical (Annex IV). The category sets the conformity assessment route and the depth of evidence a reviewer will expect in the risk assessment. Check the category against the Commission's technical descriptions before you finalize the boundary, because a product that belongs to a listed category cannot rely on a self-assessment argument alone.
Support period and changes to scope
The boundary is not fixed at release. Products get new features, new integrations and new dependencies, and each change can widen the threats in view. Set a review trigger for the assessment tied to releases, new connected services and changes to component versions. Record the date and reason for each review so that the file shows the assessment was kept current through the support period.
How an assessor tests the risk assessment
A market surveillance authority or a notified body reviews the risk assessment when it checks whether a product meets the Annex I requirements and the conformity route the manufacturer chose. The reviewer does not expect one prescribed method. Under Commission CRA FAQ 4.1.2, the regulation does not mandate a specific risk assessment methodology, but the threat model should reflect the product's intended purpose, so a product used in critical infrastructure should be assessed against threats that fit that setting. The reviewer tests whether the method is coherent, whether it follows from the intended purpose and conditions of use, and whether its conclusions drive the Annex I decisions.
- Intended purpose and conditions of use: The reviewer checks that the stated purpose, foreseeable misuse and operating environment match the threats the assessment considered.
- Point-by-point applicability: Each point (2) requirement should be marked as applicable or not, with the implementation or the justification recorded.
- Traceable method: The reviewer asks how threats were identified, rated and linked to controls, and whether the same method was applied across the product.
- Notified body scope: For class I, class II and critical products, the notified body may sample evidence more deeply than a self-assessment reviewer would.
- Evidence requested: The documented assessment, its version history, the point justifications and the link into the technical documentation.
Before a review, confirm with your notified body or the relevant authority which sampling approach and document format they expect.
Article 13(4) places the risk assessment inside the technical documentation, so a reviewer reading that file tests whether the assessment is complete, consistent and easy to follow. The reviewer does not read the assessment in isolation. They compare it against the product description, architecture, component list and test records, and they look for places where the documents disagree. A risk assessment that names a control the design does not implement is a finding, even when the control is described well.
- Internal consistency: Risks named in the assessment should correspond to design elements, components and test results in the rest of the file.
- Justifications for non-applicable points: Article 13(4) requires a clear justification whenever an essential requirement does not apply, and reviewers check each one for substance.
- Cross-references: Each implemented point (2) requirement should point to where the evidence sits, such as a design document, a test report or a configuration baseline.
- Dates and versions: The assessment should identify the product version it covers, so the reviewer can match it to the documentation for that release.
- Common finding: A justification that repeats the requirement text without explaining why it does not apply to this product.
Ask your team to walk one Annex I point from the assessment to its evidence in the file before a reviewer does.
Internal audit tests the risk assessment as a control over the product lifecycle. The question is whether the process produces a current, approved assessment at each stage, and whether engineering teams act on it. Internal audit does not need to reproduce the regulator's review. It needs to test the process, sample decisions and confirm that changes to the product triggered a reassessment when they should have.
- Ownership and approval: The audit checks who owns the assessment, who approved each version and whether that approval is recorded.
- Change triggers: Samples of design changes, new components and new integrations should show a reassessment or a documented decision that none was needed.
- Stale assessments: A support period is long, so the audit tests whether the assessment was reviewed as threats and the product evolved, not only at release.
- Decision traceability: Auditors sample a release and trace its Annex I decisions back to the assessment that supported them.
- Version history: The audit should confirm that prior versions are retained and that changes are attributable to a named person and date.
Ask internal audit to define its sample of releases and changes in advance so the test reflects the whole lifecycle, not only the most recent release.
How to build the assessment step by step
The sequence turns Article 13(2) from a general duty into a documented assessment that explains, for each Annex I Part I point (2) requirement, whether it applies and why. Each step produces an artifact that the next step depends on, so the final record can be traced from intended purpose to design decision.
Define intended purpose and conditions of use
Start by writing down what the product is for, who uses it, the environments it runs in, and the conditions under which it is used, including foreseeable misuse. Product management and the business owner draft this, and security reviews it. Article 13(3) requires the analysis to rest on intended purpose, reasonably foreseeable use and conditions of use, so this statement is the foundation for every later decision. The step is done when the statement is approved and versioned, and each later step can point back to it.
Identify assets, data flows and trust boundaries
Inventory the product's hardware and software components, the data it stores, transmits and processes, its external interfaces, and the third-party services and components it depends on. Draw the data flows and mark each trust boundary. Engineering and the platform team own this inventory, and the output is an asset register linked to the purpose statement. Components that come from outside the organization should be recorded here so that later supply chain and vulnerability work can reference them.
Model threats for the intended purpose
Identify the threat actors and attack paths relevant to the product's purpose. Commission CRA FAQ 4.1.2 does not mandate a method, but it expects threat modeling to reflect intended purpose, so a product used in critical infrastructure should consider nation-state threats. Record the threat scenarios against each asset and boundary. Ask the security team to confirm that the threat sources chosen match the purpose statement, and record any source that was excluded and the reason.
Analyze and rate the risks
Assess the likelihood and impact of each threat scenario using the method your organization already applies to security risk. The regulation does not require a particular scale, so document the scale, the criteria and who approved them. The output is a ranked risk register that states the residual risk after existing controls. Where the risk depends on conditions of use, record those conditions alongside the rating so an assessor can see why the rating holds.
Map each point (2) requirement to applies or does not apply
Work through the general requirement and points (2)(a) to (m) of Annex I Part I, one at a time. For each, record whether it applies to this product, how the product implements it, and the risk or asset that drove the decision. Where a requirement does not apply, write a specific justification, because Article 13(4) requires a clear reason. The output is a table with one row per requirement, which becomes the spine of the technical documentation. Product security and a reviewer outside the product team should both sign off the table.
Link risk results to design decisions
Trace each applicable requirement to the design, configuration or engineering decision that meets it, and to the risk it reduces. Record decisions that accept a residual risk, with the owner and the reason. This step makes the assessment useful to engineers because it shows which controls are required and which are already in place. The check is that every high-ranked risk has a named decision, and every decision points to a risk or requirement.
Approve the assessment and set review triggers
Obtain formal approval from the accountable manager, then file the document in the technical documentation with a version number and date. Define the triggers that force a review during the support period, such as a new vulnerability class affecting a component, a change in intended purpose or conditions of use, a substantial modification, or a new threat intelligence finding. Article 13(3) requires the assessment to be updated as appropriate during the support period, so the triggers and the review owner should be written into the process before release.
Keep the record current across the support period
Run the assessment through each trigger and record the outcome, whether it confirms the existing record or changes it. Use version control so the history shows what changed, when and by whom, and so the version relevant to any released product can be retrieved. Products designed before 11 December 2027 but placed on the market afterwards need not be redesigned if a current assessment shows existing measures adequately address the risks, according to Commission guidance C(2026) 5252, so a current record is what supports that position.
How products designed before December 2027 are treated
Products designed before 11 December 2027 do not automatically need redesign when the regulation starts to apply to them. Commission guidance C(2026) 5252 (section 2.7) states that such a product, if placed on the market after that date, need not be redesigned provided a current risk assessment shows that the existing measures adequately address the risks. The risk assessment is therefore the document that decides whether a legacy design can stay as it is. Without a current, documented assessment, there is no basis for relying on this transition.
To rely on the transition, the assessment must show more than that the design existed before the date. It should analyze the risks against the product's intended purpose, reasonably foreseeable use and conditions of use, as Article 13(3) requires, and it should state, point by point under Annex I Part I, which essential requirements apply and how the existing measures implement them. Reviewers will look for a dated, current analysis that names the specific measures relied on, such as the authentication model, update mechanism and data protection controls already in place, and explains why each one addresses the identified risks. Confirm with your notified body or market surveillance contact how they expect the justification to be presented before you finalize it.
The transition is not a permanent exemption. If the product is substantially modified after 11 December 2027, the regulation applies to it as a product placed on the market at that point, even if the original design predates the date. Teams should therefore record the baseline design and its assessment at the time of change, and treat any significant change to the architecture, functions or security measures as a trigger for reassessing the risks and the Annex I decisions that depend on them. Reporting duties under Article 14 apply to in-scope products whenever they were placed on the market, so the assessment and the reporting process should be planned together.
Evidence that passes and how to keep it current
A risk assessment under Article 13(2) is only as useful as the record behind it. The artifacts below show an assessor how the manufacturer reached each Annex I decision, and the upkeep steps keep them accurate through the support period.
Dated and versioned assessment record
The core document carries an issue date, a version number, the named approvers and the product release it covers. Article 13(3) requires it to be updated as appropriate during the support period, so each revision should be a new version rather than an overwrite. Check that every release that reaches customers points to a specific assessment version.
Applicability register for point (2)
For each point (2)(a) to (m) requirement, the register states whether it applies, how it is implemented, and the reasons for that answer. Where a requirement does not apply, Article 13(4) requires a clear justification, and an assessor will test that reasoning against the product's intended purpose. Review each entry whenever the product's features or interfaces change.
Threat model tied to intended use
The threat model lists the threat actors, attack paths and misuse cases considered for the product's intended purpose and reasonably foreseeable use. The Commission's FAQ notes that threat modeling should reflect the product's setting, such as nation-state threats for products used in critical infrastructure. Record which threats were excluded and why, so the exclusions can be challenged and reviewed.
Asset and component inventory
The inventory lists the product's hardware, firmware, software components, external interfaces, stored data types and third-party services that the risk assessment depends on. Generate the software part from build tooling where possible, so it matches what ships. Refresh the inventory at each release and whenever a new dependency or interface is added.
Review log and change triggers
The review log records each reassessment, who performed it, what changed and what triggered it, such as a new vulnerability, a substantial modification, a new deployment context or a change in threat intelligence. Set fixed review points and event-based triggers, and confirm the log shows that both operate. Version control on the document store makes the history of each entry visible.
Technical documentation copy
Article 13(4) requires the risk assessment to sit inside the technical documentation under Article 31 and Annex VII point 3. Keep one controlled copy that matches the assessment version in force, and confirm that the copy given to a notified body or market surveillance authority is the same version. Mismatched copies are a common reason an assessor loses confidence in the rest of the file.
What the risk assessment costs in money and effort
This table breaks down the cost components of an Article 13(2) risk assessment, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for scoping and for comparing quotes, since no fixed figures are given here.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives the cost |
|---|---|---|---|
| Internal engineering and product security time | Your own engineers, architects and product security staff | One-time for the initial assessment, recurring at each release | Number of product variants, team familiarity with threat modeling, and how many people must review the outcome |
| Threat modeling workshops | Internal facilitators, or an external facilitator if you hire one | One-time per major design area, then recurring as the design changes | Number of interfaces, trust boundaries and deployment models, plus the number of attendees from product, engineering and operations |
| Tooling, licenses or self-hosted open source | Software vendors for commercial licenses, or your team for self-hosted open-source tools and their hosting | Licenses recur; self-hosted tools carry setup and maintenance effort that recurs | Whether you need a record of requirement applicability linked to evidence, and how many products and frameworks share that record. Confirm license terms and hosting needs with each vendor. |
| External threat modeling or independent review | Outside security consultants or a reviewer you select | One-time for the initial review, optional recurring reviews for major changes | Product complexity, the intended purpose and reasonably foreseeable use, and whether the product sits in an important or critical category |
| Documentation and technical file integration | Your compliance lead, product managers and engineers who write the justification for each point (2) requirement | One-time to create, recurring to keep accurate | Number of Annex I Part I points that need a justification for non-application, and how well existing documentation is organized |
| Recurring upkeep at each release and periodic review | Product security team, with input from development and operations | Recurring for the whole support period | Release frequency, changes in components or third-party services, new threat information, and the length of the support commitment you make |
| Management review and sign-off | Accountable executives or the product governance owner | Recurring at each review cycle | Whether the assessment is reviewed by one owner or a formal committee, and how many products it covers |
Who owns the assessment, who helps and who checks it
Your organization owns the cybersecurity risk assessment and every decision in it. The regulation places the duty on the manufacturer, so no partner or auditor can accept the risks on your behalf. Your people hold the product knowledge that determines intended purpose, reasonably foreseeable use and conditions of use, which are the inputs Article 13(3) requires.
- Risk acceptance: Named managers decide which residual risks the product carries and sign off the assessment before release.
- Intended purpose and use: Product owners define the functions, users, deployment settings and misuse scenarios that the analysis must cover.
- Applicability decisions: Your engineers state whether each Annex I Part I point (2) requirement applies and how it is implemented, with justification where one does not apply.
- Maintenance: Your team keeps the assessment current across the support period as the product, its components and its threats change.
- Records: Your technical documentation owner files the assessment as part of the documentation under Article 13(4).
Before you engage anyone, confirm that you have named owners for each of these items and that the sign-off authority is written down.
An implementation partner can prepare the method, run workshops, draft documents and assemble evidence. It works for you and does not decide what risk is acceptable, and it does not issue findings, declarations or conformity statements. The Commission's FAQ notes that the regulation does not mandate a particular risk assessment methodology, so the partner's first job is to fit a defensible method to your product.
- Method design: The partner proposes a threat model and scoring approach, and it reflects the intended purpose, such as nation-state threats for products used in critical infrastructure.
- Facilitated workshops: Partner staff guide engineering, product and security staff through threat identification and point (2) applicability.
- Drafting: The partner drafts the assessment text, traceability tables and rationale for each point (2) decision, which your team reviews and approves.
- Evidence preparation: Scan outputs, component inventories, test results and configuration records are gathered in a form an assessor can trace.
- Tooling: Partners often set up a governed document store with version history so changes to the assessment remain traceable.
What the partner cannot do is certify the assessment or state that the product conforms. Ask for the written scope to say exactly which of these tasks are included.
Independent checking comes from an auditor, assessor or, for class I important products where harmonized standards are not fully applied, a notified body. These bodies test and review the assessment and the evidence behind it. Their independence is what gives the outcome weight, so the line between preparing evidence and judging it must stay sharp.
- Review of method: The assessor checks whether the method suits the intended purpose and whether the threat analysis is complete.
- Testing of decisions: The assessor samples point (2) applicability decisions and asks for the evidence that supports each one.
- Consistency checks: The assessor compares the assessment with the technical documentation and the product as built.
- Independence rules: A firm that wrote the assessment or built the controls should not also be the party that judges them. Confirm this conflict check before signing any engagement.
- Notified body route: Where a notified body is required, its role is set by the conformity assessment module, and it must be notified and listed through the Commission's NANDO system.
Before you commission a check, confirm which body is required for your product class and whether that body accepts the partner's workpapers as evidence.
Where risk assessments usually fall short
Most weak Article 13(2) assessments fail in predictable ways: they are written too late, they skip the reasoning behind decisions, or they stop at the boundary of the product's own code. The six gaps below connect through one test, whether an assessor can trace each Annex I decision back to a documented, current risk.
Written after release
An assessment drafted once the product is already on the market documents what was built, not what was decided. Article 13(2) expects the outcome to shape planning, design, development and production, so the assessment should exist before the design freeze. Check the document history: if the earliest version postdates the first release, the risk decisions were not driving the build. Close the gap by opening the assessment at the design stage and recording each design change against it.
No reasons for non-applicable points
Article 13(4) requires a clear justification whenever an essential requirement does not apply. Many assessments simply mark a point of Annex I Part I as not applicable, without saying why. An assessor reading that entry cannot tell whether the analysis considered the point or overlooked it. Close the gap by writing one sentence per excluded point that names the product feature or risk reason behind the exclusion.
Intended purpose defined too narrowly
Article 13(3) requires analysis based on intended purpose, reasonably foreseeable use and conditions of use. An assessment that describes only the ideal deployment misses misuse, integration into other systems and operation in harsher environments. Commission FAQ 4.1.2 also expects threat modeling to reflect the purpose, so a product used in critical infrastructure needs threats that match that setting. Close the gap by listing the foreseeable use cases and conditions, and asking product owners to confirm them.
Third-party components left out
Libraries, operating system images, container bases and embedded modules carry vulnerabilities into the product. Assessments that analyze only the manufacturer's own code leave those risks unmeasured, which affects decisions under the essential requirement on known exploitable vulnerabilities. Check whether every significant component appears in the analysis with its known risk and its update path. Close the gap by linking the assessment to the component inventory and its vulnerability monitoring.
No owner or review trigger
Article 13(3) requires the assessment to be updated during the support period, but many documents name no accountable owner and no event that forces a review. The result is an assessment that goes stale after the first patch cycle. Useful triggers include a new feature, a changed intended use, a significant vulnerability, a new component version and a scheduled annual review. Close the gap by naming one owner, writing the triggers into the procedure, and keeping the revision history in version control.
Disconnected from technical documentation
Article 13(4) places the risk assessment inside the technical documentation, so the two must agree. A common failure is an assessment that states a control exists while the technical file describes a different configuration, or a file that never refers to the assessment at all. An assessor will test both documents against each other. Close the gap by cross-referencing each point (2) decision to the test evidence and configuration record in the technical file.
Questions buyers ask about the risk assessment
How long does a CRA cybersecurity risk assessment take?
No supplied source gives a duration for this work, so the honest answer depends on the product. Effort is driven by how many product variants and configurations exist, how many interfaces and third-party components the product uses, how many intended purposes and deployment conditions must be analyzed, and how much design documentation already exists. A single-product, single-configuration assessment with mature design records is far shorter than a multi-variant platform with several deployment models. Ask any provider for a written scope listing the variants, interfaces and deployment conditions covered, and for the deliverables and dates tied to that scope. DeployOpen works from a written scope agreed before work starts, so the timeline is set from that scope rather than from a generic estimate.
Can our own team write the risk assessment without outside help?
Yes, the regulation places the duty on the manufacturer, so your organization can perform the assessment with its own staff. The work requires people who know the product's design, its intended purpose and how customers actually use it, along with security engineers who can reason about threats and mitigations. Teams often struggle with two parts: documenting why each Annex I Part I point (2) requirement applies or does not, and keeping the document current as the product changes. An implementation partner can prepare the system, templates and evidence, but it cannot own the conclusions. Decide early which roles your staff will fill, and confirm that the people who sign off have authority over product release decisions.
Does the CRA require a specific risk assessment methodology?
No. The Commission's FAQ states that the regulation does not mandate a specific risk assessment methodology. What it does expect is that threat modeling reflects the product's intended purpose. For example, a product used in critical infrastructure should be assessed against threats such as nation-state actors, not only opportunistic attackers. Choose a recognized, documented method, apply it consistently, and record the assumptions behind each rating. Your method should be explainable to a market surveillance authority or notified body, because the outcome must be traceable to each Annex I requirement it accepts or rejects.
How are products designed before 11 December 2027 treated?
Products designed before 11 December 2027 but placed on the market afterwards do not need to be redesigned if a current risk assessment shows that existing measures adequately address the risks. This is the position in the Commission's guidance annexed to C(2026) 5252, section 2.7. The condition is that the assessment is current, so it must cover the product as it will be sold and supported, not as it was originally designed. Also confirm the separate rule in Article 69 that the regulation applies to products already on the market only when they are substantially modified from 11 December 2027, and that Article 14 reporting applies to in-scope products regardless of when they were placed on the market.
How do we keep the risk assessment current during the support period?
Article 13(3) requires the risk assessment to be documented and updated as appropriate during the support period. In practice, this means setting triggers for review: a new release, a new interface or dependency, a changed deployment condition, a newly disclosed vulnerability in a component, or a change in the threat picture for the product's sector. Version control matters here. XWiki keeps a history of each page showing what changed, when and by whom, and lets users compare versions and roll back, which helps demonstrate how the assessment evolved. BookStack lets you assign roles and override permissions per shelf, book, chapter or page, so that only authorized reviewers can approve changes.
What should a consultant deliver for the risk assessment?
A consultant working on this topic should deliver a documented assessment that is part of your technical documentation, with several parts:
- A description of the product, its intended purpose, reasonably foreseeable use and conditions of use
- The analysis of risks against those conditions, with the method and assumptions stated
- A statement, for each Annex I Part I point (2) requirement, of whether it applies and how it is implemented
- A clear justification for any essential requirement that does not apply, as Article 13(4) requires
- A review and change history, plus the triggers and owners for future updates
Ask for these items in the written scope, along with the format and the named reviewer. DeployOpen prepares systems, controls and evidence for compliance work and documents them. Conclusions about your product remain your responsibility.
What will an auditor or notified body not do for us?
An independent assessor will not write your risk assessment, decide which requirements apply to your product, or issue conformity on your behalf. Under the regulation, the manufacturer owns the assessment and the technical documentation that contains it. A notified body, where one is required, reviews the evidence and issues its own findings, and only an independent auditor or certification body issues reports or certificates. Expect assessors to test whether the reasoning is consistent, whether the threats match the intended purpose, and whether the document reflects the product as shipped. Before engaging a provider, confirm that it will not present its work as a certification or as a substitute for your own sign-off.
How DeployOpen prepares the risk assessment for your products
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure. For the Article 13(2) risk assessment, we help your teams gather the system facts, record the analysis and keep the document current, while your organization keeps ownership of every risk decision and the final assessment.
How we scope
- We agree a written scope listing the products, versions and intended purposes the risk assessment will cover.
- We map the conditions of use, user groups and connected systems that the analysis must consider.
- We confirm which people in your organization own each risk decision before work begins.
How we build
- We document the architecture, data flows, interfaces and third-party components that feed the threat analysis.
- We record how each point (2) requirement applies or does not apply, with the reasoning written beside it.
- We prepare the threat models and risk ratings using the methodology your organization chooses.
How we hand over
- We deliver the risk assessment as a versioned document ready to include in your technical documentation.
- We provide a register linking each identified risk to its controls, test results and open items.
- We walk your compliance and engineering leads through the assessment so they can defend its conclusions.
How we support
- Ongoing support is available as a retainer to review the assessment as the product and its threats change.
- We help you schedule reviews across the support period, tied to releases, incidents and new vulnerabilities.
- Independent auditors and notified bodies remain the only parties that assess conformity and issue certificates.
