A defensible, repeatable information security risk assessment and treatment plan, aligned to ISO 27001 clause 6.1.2 and built for your team to reuse, not a one-off consultant deliverable.
Companies that need a defensible information security risk assessment, usually because ISO 27001 clause 6.1.2 requires one, because SOC 2's CC3 criteria expect a formal risk process, or because a customer or investor has asked how you identify and manage security risk. It also suits companies whose existing risk register was built once, filed, and has not been touched since, which is a very common situation and one auditors identify quickly.
A structured inventory of information assets, mapped against realistic threats and vulnerabilities specific to your environment, not a generic risk library.
A risk methodology that satisfies ISO 27001 clause 6.1.2 and produces a register your certification body will recognise.
A consistent, defensible scoring model your team can reapply independently on future assessment cycles.
Prioritised treatment options (mitigate, transfer, avoid or accept) tied to specific Annex A controls and owners.
A living register, not a one-time PDF, structured for ongoing review at your management review cycle.
Available as a standalone assessment or bundled into ISO 27001 certification preparation.
The output of a risk assessment is not a document. It is a set of decisions: what could go wrong, how bad it would be, how likely it is, and what you are going to do about each one. The register is simply where those decisions are recorded so they can be reviewed later.
This matters because a great many risk registers are written to satisfy a requirement rather than to inform anything. You can usually tell within a minute. Generic risks copied from a library, impact and likelihood scores with no stated basis, treatment decisions that amount to a control name and no owner. Auditors can tell too, and it is one of the areas where a superficial approach is most visible.
A useful assessment connects to reality in both directions. It starts from the assets and processes your business actually depends on, and it ends in treatment decisions that someone owns and that map to controls you can evidence.
ISO 27001 requires a defined and repeatable methodology. It deliberately does not prescribe one, which leaves organisations free to choose between qualitative scoring, quantitative modelling, or something in between.
For most companies, a clear qualitative approach applied consistently is worth more than an elaborate quantitative model applied once. What the standard is really testing is whether two people assessing the same risk would reach comparable conclusions, and whether the assessment can be repeated next year and compared against this one. A five by five impact and likelihood matrix with written definitions for each level achieves that. A model with false precision usually does not, and is harder for your team to maintain after we leave.
We build the methodology to be reused. That is the point. A risk assessment that only works while a consultant is in the room has failed the requirement, because clause 6.1.2 expects the process to be repeatable by you.
Under ISO 27001 the risk assessment drives the Statement of Applicability, which records which Annex A controls apply and why. This is the link auditors trace most often, and where inconsistency shows up fastest.
If your register identifies a significant risk around privileged access but your Statement of Applicability excludes the relevant access control, that contradiction is difficult to explain. Equally, if you have included every control regardless of your actual risks, the assessment is not doing the work the standard expects of it. We check the two documents against each other explicitly, because a certification body will.
We work with your team to identify information assets in scope (systems, data stores, third-party services) before assessing anything.
Realistic threats mapped to each asset, grounded in your actual architecture rather than a generic threat catalogue.
Consistent impact and likelihood scoring produces a ranked risk register your leadership can act on.
Each significant risk gets a treatment decision and an owner, not just a description sitting in a spreadsheet.
You get one round to act on the treatment decisions we agreed. We re-review those items and issue the final risk register.
We set a review cycle (typically annual, or after significant change) and train your team to run it independently going forward.
After the draft risk register and treatment plan are issued, you get one round to act on the treatment decisions we agreed. We then re-review those specific items and issue the final register, so what you present to an auditor reflects the treatments you have actually applied.
Risks that are not specific to your architecture and business model are obvious to auditors and useless to you.
If high likelihood is not defined, scores are opinions and cannot be repeated consistently next cycle.
A treatment plan without accountability is a list of intentions, and it will be tested against what actually changed.
Risk registers age quickly. New products, regions, vendors and incidents all change the picture, and the standard expects reassessment.
A focused risk assessment for a mid sized software company typically takes two to three weeks, including workshops with the people who genuinely understand each area, the scoring exercise, and the treatment plan. Where it forms part of a wider ISO 27001 preparation programme it runs earlier in that timeline, because the Statement of Applicability and much else depends on it. Reassessment thereafter is usually annual, plus after any significant change such as a new product line, a new region or a material incident.
We're consultants. We'll get your controls in shape and get you ready for the audit, but we don't hand out ISO 27001 certificates or sign SOC 2 reports, because the rules quite rightly don't let the firm that prepared you be the firm that passes you. That job goes to an independent certification body or CPA firm, and we'll help you find a good one. More on where exactly that line sits in our independence statement.
Sign a 2-year agreement with pricing locked in upfront, and your first year of any one service is completely free. Adding more than one service in year one? We give you the highest-value one free and a bundle discount on the rest. See how the offer works →
Yes, clause 6.1.2 requires a defined, repeatable risk assessment methodology and clause 6.1.3 requires a treatment plan. This is one of the most heavily scrutinised parts of a certification audit.
SOC 2's CC3 criteria also expect a formal risk assessment process, so most SOC 2 clients benefit from this even without ISO 27001 in scope.
At least annually, and after any significant change: new product line, new region, new critical vendor, or a security incident.
That's the goal. We hand over a methodology and register template your team can reapply, rather than creating dependency on us for every cycle.
It can be. Many clients include it as part of that programme. It's also available standalone if you just need a defensible risk assessment now.
Yes, in substance. SOC 2's CC3 criteria expect a formal process for identifying and assessing risks, even though the requirement is expressed differently from ISO 27001 clause 6.1.2. Most companies satisfy both with a single well built process.
There is no target number, and padding a register to look thorough is counterproductive. What matters is that the risks that genuinely matter to your business are present, assessed consistently, and have owned treatment decisions.
A gap analysis compares your current state against the requirements of a standard. A risk assessment identifies what could harm your business and how you will address it. The standard requires both, and they answer different questions.
That is the intention. We hand over the methodology, the scoring definitions and the register structure so your team can repeat the exercise. Clause 6.1.2 expects a repeatable process, not a consultant dependency.
Risk acceptance is a legitimate treatment option provided the decision is made by someone with the authority to make it and is recorded with its rationale. What auditors object to is implicit acceptance, where a risk is simply left unaddressed with no decision recorded.
One remediation cycle is included as standard in every engagement. You get one round to apply fixes to what we raised, we re-check those specific findings, and the final report reflects your corrected state rather than the position we found at the start. What sits outside that is our engineers implementing the fixes on your behalf, rather than verifying yours, and any further rounds beyond the first. Both are quoted separately and transparently before any work starts.
Tell us your target date and current state. We'll come back with a fixed-scope proposal within two business days.
Book a discovery call