Cybersecurity risk assessment services

A cybersecurity risk assessment includes five parts. Scope and risk criteria: the assets, systems, data and third parties covered, plus the likelihood scale, the impact scale and the threshold above which a risk needs treatment. Identification: the threats and vulnerabilities that apply to each in-scope asset, gathered with the people who operate those systems. Analysis: a likelihood and impact rating for every risk, with the reasoning written next to the rating. Treatment: a decision to mitigate, transfer, avoid or accept each risk, with a named owner and a date. Documentation: the risk register, the risk treatment plan and the procedure used, kept as evidence. The steps follow ISO/IEC 27001:2022 clauses 6.1.2 and 6.1.3, with method guidance from ISO/IEC 27005 and NIST SP 800-30 Rev 1.

Each engagement answers a separate question and produces a separate document. A cybersecurity risk assessment answers which risks your organization carries, how likely and how damaging each one is, and who has decided what to do about each one. The output is a rated risk register with a treatment plan. A security capability assessment measures the maturity of your security capabilities, around 19 of them, and produces a current state report with a sequenced remediation plan. A readiness and gap assessment measures the distance between your controls and one framework, such as SOC 2 or ISO 27001, and produces a gap list and a realistic audit date. Truvo offers all three and recommends one on the scoping call based on what the auditor, customer or board asked for.

ISO/IEC 27001:2022 sets the requirements: clause 6.1.2 for the risk assessment process, including risk criteria, risk owners and results that are consistent and comparable, clause 6.1.3 for risk treatment and the Statement of Applicability, and clause 8.2 for performing assessments at planned intervals. ISO/IEC 27005 gives guidance on how to carry out the assessment, with both event-based and asset-based identification. NIST SP 800-30 Rev 1 describes four steps: prepare, conduct, communicate and maintain. SOC 2 places the requirement in the AICPA Trust Services Criteria CC3.1 to CC3.4, covering objectives, risk identification and analysis, fraud risk and significant change. ISO/IEC 42001 adds an AI risk assessment and an AI system impact assessment. CPCSC inherits the risk assessment controls in ITSP.10.171, and the HIPAA Security Rule requires a risk analysis at 45 CFR 164.308(a)(1)(ii)(A). One method satisfies all of them, so adding a second framework later is mapping work.

Once a year, and again whenever something significant changes. ISO 27001 clause 8.2 requires risk assessments at planned intervals and when significant changes are proposed or occur, and certification auditors ask for the dated record of the last assessment. SOC 2 CC3.4 requires the entity to identify and assess changes that could significantly affect internal control, and in our experience a Type 2 auditor expects a risk assessment performed within the review period. An annual cycle timed to the audit calendar meets both. Significant changes include a new product line, a new cloud provider or critical vendor, an acquisition, an AI system entering production, and a security incident.

Scope drives the cost. Six factors set the effort: the number of in-scope systems, applications and data stores, the number of third parties that hold your data or access your systems, how many frameworks the register maps to, whether a current asset inventory and a prior register exist, whether AI systems are in scope and need an ISO 42001 impact assessment, and how quickly risk owners are available for the treatment decisions. Scope and timeline are agreed in writing before the engagement starts, so the fee follows from a known scope.

Six documents: a scope statement with the risk criteria, a rated risk register with the reasoning behind each rating, a risk treatment plan with an owner and dates on every risk, a record of accepted risks with who accepted each one, a mapping to the clause or criterion that required the assessment, and the written procedure for the next review. Where ISO 42001 is in scope, an AI system impact assessment is added. The register is loaded into your GRC platform so the auditor reads one source.

A GRC platform such as Vanta, Drata or Secureframe holds the register and suggests a starting library of risks. The service decides which of those risks apply to your environment, rates them against your business impact, and records why leadership accepted the risks leadership accepted. In one SOC 2 preparation we supported, risk entries were split between the platform and a spreadsheet, two people had logged the same MFA risk separately, and several remediated risks still showed as open. The finished register goes back into the platform as the single record the auditor reads.

ISO/IEC 42001 asks for two assessments where ISO 27001 asks for one. The AI risk assessment in clause 6.1.2 covers risk to the organization, in the familiar way. The AI system impact assessment in clause 6.1.4 covers the consequences for the people and groups an AI system affects, which brings a different set of stakeholders, and teams extending an existing ISO 27001 management system often miss this second assessment. Where an AI management system is in scope, Truvo produces both, and the register records which AI system each risk attaches to so a model change has a clear set of affected risks.

The timeline follows the number of in-scope systems and how much documentation already exists, and the timeline is set before the engagement starts. A senior security risk assessment consultant leads the work from scoping to handover. From your side, the engagement needs the people who operate the systems for the identification work and whoever holds authority to accept risk for the treatment decisions. Access to the risk approver is the usual cause of delay: a register is complete only once accepted risks carry a signature from someone in your organization.

Access happens inside your environment, in your platforms and in the third-party systems you grant access to. Truvo does not take custody of, store or host your production data or personal information for a risk assessment. For teams whose own customers ask the same question in a security review, the engagement records this as part of the evidence.