Scrutineer · Platform

Cyber risk assessment software for IT and security risk teams

Cyber risk assessment software turns a once-a-year spreadsheet exercise into a live view of where you actually stand. Scrutineer connects read-only to your cloud, identity and ticketing systems, checks your controls against the frameworks you carry, and surfaces every gap as a scored risk with a likelihood, an impact and a named owner. You stop guessing which weaknesses matter and start working a ranked list.

The assessment does not go stale the day after you finish it. Scrutineer watches the same controls continuously, so a bucket that loses encryption or a former employee with a live token shows up as a new risk that day, not at your next annual review. It scores your third parties on the same scale, because a vendor holding your data is part of your risk picture. This is decision support and audit readiness; the formal attestation is issued by an accredited independent auditor.

or try it below ↓

Control-mapped findings · linked evidence · you decide what to remediate

The Scrutiny Desk

Illustrative sample · not an audit attestation

SOC 2 ISO 27001 HIPAA GDPR PCI DSS

Controls in evidence-linked report out

AI scrutinizes you decide

Why it works

What you get with cyber risk assessment

The most expensive finding in US health-sector enforcement is the assessment itself

If you want a single reason to take the risk analysis seriously rather than treating it as paperwork for the audit binder, read the HHS Office for Civil Rights settlements. OCR runs a dedicated Risk Analysis Initiative, and the citation is almost always the same clause: failure to conduct an accurate and thorough risk analysis under 45 CFR 164.308(a)(1)(ii)(A). In February 2026 OCR announced a $103,000 settlement with Top of the World Ranch Treatment Center in Illinois, the eleventh action under that initiative. On April 23, 2026 it announced four ransomware settlements at once, totaling $1,165,000, each with a two-year corrective action plan under OCR monitoring, and every one included a failure to conduct an accurate and thorough risk analysis before the breach. In August 2026 two self-funded group health plans settled for a combined $695,000 on the same finding. Note what is not being cited: not a missing firewall, not an unpatched box. The finding is that nobody wrote down, accurately and across the whole environment, where the data was and what could go wrong with it.

Enterprise-wide is a legal term here, and partial scope is the usual failure

The pattern in those settlements is not that entities skipped the assessment. Many had one. What OCR found was that it covered part of the environment: one application, one data center, the systems the security team owned, and not the laptops, the backups, the vendor-hosted systems or the acquired subsidiary. An assessment that stops at the boundary of what is convenient to inventory is the specific thing being penalized. That has a practical consequence for tooling. The hard part of a cyber risk assessment is not scoring, which any spreadsheet does. It is maintaining an accurate inventory of the systems and data flows in scope, because that inventory is what determines whether the assessment is thorough or merely tidy, and it is the part that goes out of date fastest.

An assessment with no date on it is worth very little

Every framework that asks for a risk assessment also asks, explicitly or in practice, when it was done and by whom. An annual assessment is genuinely current for a few weeks. By month six the environment has moved: new systems, a new vendor with production access, a changed data flow, an acquisition. The gap between the last assessment and today is not a documentation problem, it is the window in which the risk you would have found is unmanaged and undocumented. Continuous re-scoring closes it, but the more important discipline is simpler and often skipped: record the date and the approver on every risk decision, including the ones where you accepted the risk. Accepted risk with a name and a date on it is a defensible position. The same decision, undocumented, looks identical to negligence after an incident.

What it handles

Controls in, an evidence-linked report out

Point Scrutineer at a framework or a vendor and it maps every control, pulls the evidence it can find, flags the gaps and scores the risk, returning a report with linked evidence and a prioritized remediation list. Scrutineer is decision support for readiness, an accredited auditor still issues the attestation.

Identifies control gaps across every framework you carry
Scores each gap by likelihood, impact and residual risk
Pulls control evidence automatically and read-only
Ranks remediation so the biggest exposure is worked first
Re-assesses continuously as controls drift or change
Scores third-party and vendor risk on the same scale
Keeps the scope inventory current, since an assessment that misses systems is the finding regulators actually cite
Records who accepted each residual risk and on what date, because an accepted risk with a name on it is defensible and an undocumented one is not

CYBER RISK ASSESSMENT readiness_report

READINESS · 82%

ACCESS CONTROL 91

evidence · MFA enforced and access reviews evidenced.

CHANGE MGMT 78

evidence · Mostly covered; one approval log left untested.

VENDOR RISK 64

evidence · Two subprocessors missing a current review.

ENCRYPTION 86

evidence · Data encrypted in transit and at rest, evidenced.

Example report layout, not customer data

Why Scrutineer

One platform that maps controls and scores risk

Not a static questionnaire, not a pass-fail black box, and not a spreadsheet you maintain by hand. Live control mapping across SOC 2, ISO 27001, HIPAA, GDPR and PCI, automatic evidence and a prioritized gap list, returned as a report you can act on. The AI scrutinizes, you decide.

Mapped to real controls

Every framework is broken down into the controls it actually requires, each scored on a red to amber to green scale, so readiness stays transparent and consistent.

Evidence behind every finding

Each control links to the exact evidence that satisfies it, the policy, the config, the log line, so the finding is auditable and your readiness is defensible.

A prioritized gap list

Open gaps roll up into a ranked remediation list, so the highest-risk findings sit at the top and your team fixes what matters before the audit begins.

Risk assessment obligation reference

Which risk assessment each US obligation actually requires, and what the output has to be

Most guides explain how to score a risk. Almost none say which assessment you owe, to whom, in what form, or what specifically gets cited when it is wrong. Those are different questions, and a program that runs one excellent enterprise assessment can still fail three of the rows below, because several of them ask for a separate document rather than a section of yours.

The obligation	What it actually asks for	What the deliverable has to be	How often	What gets cited when it goes wrong
HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A)	An accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of all electronic protected health information the entity holds	A written analysis covering the entire environment, not one system or one application	No fixed interval in the rule. In practice annually and after any material change	This is the single most cited finding in OCR Security Rule settlements, including four ransomware resolutions totaling $1,165,000 announced April 23, 2026
FTC Safeguards Rule, 16 CFR part 314	A written risk assessment identifying reasonably foreseeable internal and external risks to customer information, with criteria for evaluating and categorizing them	A written document. The rule says written, and an undocumented assessment does not satisfy it	Periodically, and whenever a reassessment is warranted by a material change	Non-bank financial institutions, which is a far wider set of companies than most readers assume
PCI DSS v4.0.1, requirement 12.3	A targeted risk analysis for each requirement where you set your own frequency, and for any control met through the customized approach	A documented analysis per requirement, not one assessment for the whole program	Reviewed at least once every 12 months, and on significant change	Assessors ask for these individually. A single enterprise risk assessment does not substitute for them
ISO/IEC 27001, clause 6.1.2	A defined and applied information security risk assessment process with documented criteria, including risk acceptance criteria, producing consistent and comparable results	Documented information: the process, the results, and the risk treatment plan behind the Statement of Applicability	At planned intervals and when significant changes occur	The certification auditor tests whether the process was actually followed, not whether the output looks sensible
SOC 2, common criteria CC3	That the entity specifies objectives clearly enough to identify risks, identifies and analyzes them, considers fraud risk, and identifies changes that could affect the system of internal control	Evidence that risk assessment happened during the period, usually minutes, a register and dated decisions	Across the whole review period for a Type 2, not once at the start	A register that was created the month before fieldwork and shows no activity during the period
NIST SP 800-171 and DFARS 252.204-7012	A self-assessment against the 800-171 requirements using the 800-171A objectives, producing a score	A score posted to SPRS, plus a system security plan and a plan of action and milestones	The score reflects the date it was filed, so it needs refreshing as gaps close	A stale SPRS score. Third-party CMMC Level 2 assessment is suspended as of July 13, 2026, but the self-assessment duty is not
NIST SP 800-30	Nothing. It is a methodology, not an obligation, and no one can require you to use it	Whatever your program defines. It gives you threat sources, vulnerabilities, likelihood and impact scales	Not applicable	Nothing, but it is worth naming in your policy, because auditors accept a recognized methodology far faster than a bespoke one

Row one is the one to plan around. Across the OCR Risk Analysis Initiative the finding is rarely that no assessment existed. It is that the one that existed did not cover everything, which is why scope inventory matters more than scoring methodology.

Good questions

Questions about cyber risk assessment

Cyber risk assessment software identifies the vulnerabilities and control gaps that threaten an organization, scores each one by likelihood and impact, and helps teams prioritize remediation. Instead of a manual spreadsheet review done once a year, it maps risks to your controls, frameworks, assets and owners, and keeps the assessment current as your environment changes.

A cybersecurity risk assessment scopes the systems and data in play, identifies the threats and control gaps against them, then scores each risk by likelihood and impact to produce a ranked list. NIST SP 800-30 is the common methodology. Software speeds every step by pulling live evidence, applying consistent scoring, and reporting findings to the people who decide what to fix.

A risk assessment looks forward: it estimates which weaknesses are most likely to hurt you and how badly, so you can prioritize. A security audit looks at a point in time and checks whether you meet a defined standard, and an independent auditor issues the result. You use the assessment to decide where to invest before the audit measures whether the controls hold.

A vulnerability scan finds technical flaws in systems, like an unpatched server or an open port. A cyber risk assessment is broader: it weighs those technical findings alongside process and control gaps, scores each by business impact, and ranks them. Most teams feed scan output into the risk assessment rather than treating the two as the same thing.

A full assessment at least annually is the baseline most frameworks expect, plus a fresh one after any major change such as a new system, an acquisition or a serious incident. The stronger approach is continuous: software that re-scores risk the moment a control drifts closes the blind spot between scheduled reviews, which is where most surprises live.

It is the requirement at 45 CFR 164.308(a)(1)(ii)(A) to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of all electronic protected health information a regulated entity creates, receives, maintains or transmits. The two words that decide enforcement outcomes are accurate and thorough, which OCR reads as covering the whole environment rather than the systems that were convenient to inventory.

The Security Rule sets no fixed interval. What OCR expects in practice is at least annually and again after any material change: a new system holding electronic protected health information, an acquisition, a new vendor with access, or a security incident. The date matters as much as the content, because an assessment that predates the environment it describes is the pattern that appears repeatedly in settlements.

In HIPAA usage they are the same thing, and the rule calls it risk analysis. Outside HIPAA, risk assessment is the general term for identifying, analyzing and evaluating risk, and risk analysis is sometimes used for just the analysis step within it. If a healthcare customer or a regulator asks for a risk analysis, they mean the Security Rule requirement, and giving them a vulnerability scan report will not satisfy it.

No. A penetration test tells you whether specific defenses can be defeated by a specific tester in a specific window. A risk assessment covers the whole environment, including process and administrative gaps a tester never touches, and produces scored, owned risks. Test results are a valuable input to the assessment. They are not a substitute for it, and no framework treats them as one.

NIST Special Publication 800-30 is the guide for conducting risk assessments. It supplies the vocabulary most US programs use: threat sources, threat events, vulnerabilities, likelihood, impact and the resulting level of risk, with semi-quantitative scales for each. It is a methodology, not a mandate. Nobody can require you to use it, but naming a recognized methodology in your policy shortens the conversation with an auditor.

Write the scale down and apply it mechanically. Define what each level of likelihood and impact means in terms your business recognizes, in dollars, hours of downtime or records exposed, and score against those definitions rather than a feeling. The point is comparability: two assessors scoring the same risk should land in the same place, which is exactly what ISO 27001 clause 6.1.2 asks for when it requires consistent, valid and comparable results.

Each entry needs the risk described in plain terms, the asset or process it threatens, the controls currently reducing it, an inherent and a residual score, a named owner, a treatment decision, and a date. The two fields most registers omit are the ones that matter after an incident: who accepted the residual risk, and when. An accepted risk with a name and a date is a defensible decision. The same decision undocumented is not.

For the mechanics, largely yes. Software keeps the scope inventory, applies scoring consistently, pulls evidence of control state, and produces the register and the report. What it does not replace is judgment about your specific business: which processes really matter, what a realistic worst case looks like, and how much residual risk leadership is willing to carry. Most programs use tooling for the assessment and expertise for the interpretation.

Read every compliance and risk question

Keep reading

Guides that go deeper on risk assessment

How to conduct a cybersecurity risk assessment

The step-by-step version, from scoping the environment to writing risks somebody will actually own.

Read the guide

HIPAA compliance checklist

Where the Security Rule risk analysis sits among the rest of the obligations, and what OCR looks for first.

Read the guide

Best GRC software

The platform comparison for teams whose risk register has to share a control library with compliance work.

Read the guide

Explore more

More ways to scrutinize compliance and risk with Scrutineer

SOC 2 compliance

Map controls to the Trust Services Criteria, collect evidence, and close gaps before audit.

Learn more

SOC 2 compliance software

A platform that maps SOC 2 controls, automates evidence, and tracks readiness continuously.

Learn more

ISO 27001 compliance

Map your ISMS to Annex A, automate evidence, and stay certification-ready.

Learn more

See every use case See pricing Back to Scrutineer

Stop guessing about readiness. Scrutinize on real evidence.

Point Scrutineer at a framework or a vendor and it maps every control, gathers evidence and scores the risk, returning an evidence-linked report and a prioritized gap list. The AI scrutinizes, you decide.

See pricing

SOC 2, ISO 27001, HIPAA, GDPR & PCI · evidence-linked controls · readiness, not certification