What a Safeguard Readiness Score Counts, and What It Does Not

A Safeguard readiness score is the share of a framework's in-scope requirements that currently pass, either because a scan or automated test found them met or because a person attested them with named evidence. Requirements waiting for evidence count as not passing, and scoped-out requirements leave the score. It is Safeguard's assessment of what it can see, not an audit opinion or a certification.

That one paragraph is the answer most people need. The rest of this post is for the person who has to put the number in front of a board, a customer or an auditor and defend it: how each requirement is decided, why the number moves, why it sometimes drops when nothing in your controls changed, and the sentence you should put next to it so nobody reads it as more than it is.

Key takeaways

• The Compliance and GRC suite (GA) gives every framework you switch on a readiness score: requirements passed divided by requirements in scope, shown as a whole percentage.
• Every requirement is one of three kinds: decided by a scan, scan checks a prerequisite (shown as "Scan, then evidence"), or needs evidence. Across the library most are scan-decided, but some frameworks, SOC 2 among them, are mostly evidence.
• A requirement waiting for evidence stays in the denominator. It drags the score down until a compliance reviewer attests it, which is the honest outcome.
• Automation wins over people. A failing scan verdict or a failing automated test fails the control even if someone attested it. A test that could not run leaves the control unproven, and only an attestation can pass it.
• The score shows 100 only when every in-scope requirement passes. While anything is open, the app holds it at 99 or below, so rounding cannot print a perfect score over a gap.
• Scoping a requirement out needs a written justification, and auditors read it. Scoping is a judgement, not a way to lift the number.
• Lion evidence mapping (GA) helps map and narrate evidence; it does not decide whether a requirement passes.
• SBOM generation and SCA (GA) feed the scan-decided requirements, which is why a new component with no supplier or version can lower a score overnight.
• The score is not a Trust Center claim, not an audit opinion and not a certificate. An accredited auditor or certification body issues those.

Why a percentage is not an opinion

Before looking at the product, it helps to be precise about what auditors and frameworks actually produce, because the gap between "requirement met" and "control operating effectively" is where readiness numbers get misread.

What a SOC 2 report actually is

A SOC 2 report is the output of an examination performed by a licensed CPA firm. The AICPA's SOC 2 guide describes it as an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy, written for CPAs in public practice who perform these engagements. The guide calls it an assertion-based examination: management describes its system and asserts that its controls are suitably designed (and, for a Type 2, operated effectively over a period); the practitioner then gathers evidence and expresses an opinion on those assertions. The criteria are the 2017 Trust Services Criteria with the revised points of focus published in 2022, and the guide is updated as of 15 October 2022.

Two things follow. First, the opinion belongs to the CPA. No tool, dashboard or vendor can issue it. Second, the opinion is about design and, in a Type 2, about operation over a period. A readiness percentage is a count at a moment in time. It can tell you that, today, the evidence for a criterion exists and an automated check passed. It cannot tell you that the control operated every day of a twelve-month window, that the population an auditor would sample from is complete, or that management's system description is fair.

The AICPA itself is worried about this gap. Its SOC suite page currently carries guidance on business arrangements between CPA firms and SOC 2 tool providers and warns that promises of "fast and easy" threaten SOC credibility. A readiness score that is presented as if it were a SOC 2 result is exactly the kind of shortcut that warning is about.

How a federal assessor phrases a result

NIST SP 800-53A Rev. 5, the assessment companion to the SP 800-53 control catalogue, gives a useful vocabulary. Assessors apply assessment procedures to a control and record findings of "satisfied" or "other than satisfied" for the portion of the control each determination statement covers. They look at four kinds of assessment objects: specifications (policies, procedures, plans, designs), mechanisms (the hardware, software or firmware safeguards), activities (things people do) and individuals.

That split maps neatly onto how Safeguard sorts requirements. A scan can look at a mechanism: the software inventory of a product, its component versions, its hashes, its known vulnerabilities. It cannot examine a specification that lives in a policy document, an activity such as a quarterly access review, or an individual's training record. Those need evidence that a person puts forward and another person accepts. A readiness score that hides the difference makes mechanisms and paperwork look like the same kind of proof.

ISO/IEC 27001 and NIST CSF 2.0 do not ask for a single number either

ISO/IEC 27001:2022 puts performance evaluation in clause 9: monitoring, measurement, analysis and evaluation (9.1), internal audit (9.2) and management review (9.3). The standard asks you to decide what you monitor and measure, how, when and by whom, and to keep documented evidence of the results. A readiness score can be one of your measures. It is not the evaluation itself, and it is not the certification body's audit. (The ISO text is sold by ISO and its national members; read your licensed copy for exact wording.)

NIST CSF 2.0 (CSWP 29, February 2024) is even more explicit. It says the CSF does not prescribe how outcomes should be achieved. Its Organizational Profiles describe a Current Profile (outcomes you are achieving) and a Target Profile (outcomes you have chosen to aim for), and its Tiers, from Partial (Tier 1) to Adaptive (Tier 4), characterise the rigour of your risk governance and management. None of these is a percentage. If you report CSF progress with a Safeguard readiness score, say clearly that the score counts requirements Safeguard checks, and that Profiles and Tiers are your own judgement.

Who owns which line

The IIA's Three Lines Model is a helpful frame for anyone presenting a score to a board. Management, the first and second lines, owns the controls and the monitoring of them. Internal audit, the third line, gives independent assurance. External auditors sit outside all three. A readiness score is a management monitoring tool. When it is presented to a board, it should be presented as management's own view of its programme, not as assurance from anyone independent.

How Safeguard covers a framework

The Compliance and GRC suite (GA) is organised into areas you will see on the Compliance screens: Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. The library holds hundreds of frameworks: national data-protection, cybersecurity and sector laws, industry standards such as SOC 2, ISO/IEC 27001 and PCI DSS, and Safeguard's own supply-chain policies. Each one is covered in up to four layers, according to Safeguard's frameworks documentation.

1. Scan requirements. Every framework has requirements that Safeguard checks on each scan of a product, against what the scan found, including the product's software inventory (SBOM). Each framework's docs page lists them and what Safeguard checks for each one.
2. Controls. On a framework's Controls tab, its scan requirements appear as controls. For many frameworks, Safeguard's control catalogue adds more of that framework's controls, which you evidence with automated tests, uploaded evidence, policies and attestations.
3. Automated tests. Systems you connect (cloud accounts, identity providers, code hosts and others) run automated tests. These map directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, and to the CIS benchmarks. Through the crosswalk, that evidence can reach equivalent controls of related frameworks. For any other framework you can link tests to controls yourself. Roughly 50 evidence connectors are live today, with more on request.
4. Policy templates. Every framework has a standard set of policy templates adapted to it, and some frameworks have templates written specifically for them.

For most frameworks in the library, coverage is the scan requirements, the controls and your own evidence. Automated tests reach a small group of widely used frameworks directly. That matters for the score: a framework without automated test coverage relies more on people attesting evidence.

Lion (GA), which some of the docs spell Lino, is the AI model family behind regulatory mapping, evidence quality checks, policy authoring and audit-grade summaries. It helps you get evidence to the right control and write it up clearly. It is not the thing that decides whether a requirement passes; the rules below are.

Which requirements a scan decides, and which need a person

Safeguard marks every requirement with one of three labels. You will see them in the "Decided by" column on each framework's docs page.

Across the library as a whole, Safeguard's docs say most scan requirements are decided by a scan, a few check a prerequisite, and a small share need evidence a scan cannot see. That ratio is not the same for every framework, and the difference is the single most important thing to understand before you compare scores across frameworks.

Example: SOC 2 is mostly evidence

Safeguard's SOC2 Type 1 page describes the framework as a point-in-time assessment of control design against the full CC1 to CC9 common criteria, with Availability, Confidentiality, Processing Integrity and Privacy visible as optional scope. Read down its "Decided by" column and the picture is lopsided:

• Scan: CC7.1 Vulnerability Detection and Monitoring. Recurring vulnerability scanning of system components is something a scan can actually see, so the scan decides it.
• Scan, then evidence: CC6.1 Logical Access Security, CC6.8 Prevention and Detection of Unauthorized Software, CC7.2 Monitoring of System Components for Anomalies, CC9.2 Vendor and Business Partner Risk Management, and PI1.5 Storage Integrity. For each, the scan checks a software-inventory prerequisite (a complete, current component inventory; verifiable provenance such as integrity hashes and known licences; version identification of every component; a complete third-party supplier inventory; integrity hashes on stored components). The docs say plainly that full satisfaction also needs things a scan cannot see, such as SSO and MFA, least privilege, vendor assessments and agreements.
• Evidence: everything else, from CC1.1 Commitment to Integrity and Ethical Values and CC1.2 Board Oversight through the confidentiality and privacy disposal criteria.

So a fresh SOC 2 programme in Safeguard will start with a low readiness score even if every product scan is clean. That is correct. SOC 2 is mostly about governance, people and process, and the score is telling you that most of the work is evidence you have not attested yet. Connecting your identity provider, cloud and code host so automated tests can evidence some of those controls, and attesting the rest, is what moves it.

Example: NIST SSDF is all scan requirements

At the other end, Safeguard's NIST SSDF page lists six scan requirements, all decided by a scan, plus further controls from the catalogue. The scan requirements are tied to SP 800-218 tasks that a software inventory can actually show:

• PS.3.2 (collect, safeguard, maintain and share provenance data for each release, such as an SBOM): Safeguard checks for an SBOM that identifies the creating tool or organization.
• PS.2.1 (make software integrity verification information available to acquirers): Safeguard checks for cryptographic hashes on released components.
• PW.4.1 (acquire and maintain well-secured components): Safeguard checks that each component's supplier is identified.
• PW.4.4 (verify acquired components): Safeguard checks for precise component identifiers such as package URLs.
• RV.1.1 (gather information on potential vulnerabilities): Safeguard checks that every component carries an exact version so advisories can be matched.
• A complete component records requirement for the PW.4 practice: name and version for each component.

Those checks line up with the NTIA minimum elements for an SBOM (July 2021), which list supplier name, component name, version and other identifiers among the baseline data fields. That is why SSDF scan requirements can reach a high score on the strength of good SBOM data alone, while SSDF's process practices (defining security requirements, toolchains, review and testing, response and root cause) sit in the catalogue controls and need your evidence.

The lesson for anyone comparing frameworks: a 90 on SSDF scan requirements and a 30 on SOC 2 do not mean you are three times better at secure development than at governance. They mean the frameworks are made of different kinds of requirements. Always read the score with the coverage line beside it.

How the readiness score is computed

The docs give the rule in four lines:

• A requirement passes on a scan that finds it met, or on an attestation by a person that names its evidence.
• A requirement waiting for evidence counts as not yet passing. It stays in the score until someone attests it.
• A requirement a person scopes out, with a written justification, leaves the score.
• The score reads 100 only when every in-scope requirement passes.

The app shows the same rule in a tooltip next to the score: readiness equals controls passed divided by all controls in scope, a control passes on an automated check or on an attestation that names its evidence, and anything else counts as not yet passing. (On the Controls tab, scan requirements appear as controls, which is why the docs say "requirements" and the app says "controls".)

The rules in more detail

The app applies a few more rules that are worth knowing, because they explain most "why does it say that" questions.

Automation is the truth where it exists. A control has up to two automated verdicts: the scan's own verdict, and the rolled-up result of any automated tests mapped to it from connected systems. If either one is failing, the control fails, even if a person attested it or set it to passing by hand. You cannot attest your way past a failing check. Fix the cause, or scope the resource out of the test through an approved exclusion.

A test that could not run proves nothing. If a mapped test errored, or a passing result has gone stale because the test is disabled or overdue, the control is unproven. Automation can no longer pass it, and it has not shown a failure either. Only an attestation with evidence can pass it until the test runs again.

A status set by hand does not count. Someone can set a control to "passing" without attesting it. The score ignores that. The app shows such a control as needs review, never as passing, and it stays in the denominator as not yet passing.

Attestations must name their evidence. The attestation form is titled "Attest this control". Its field, "What you reviewed", asks you to describe the evidence and why it satisfies the control, and it is recorded with your name and the time; auditors see it. A one-word attestation is rejected; you need a short description or an evidence reference. The app counts an attestation as soon as it is saved, without waiting for the next scan.

An approved policy can evidence a control nothing else judges. Where no scan or test judges a control, an approved policy in force that maps to it (approved, review date not passed) counts as that control's evidence. It never overrides automation: a failing test still fails the control.

Scoping out takes a justification. The "Mark not applicable" dialog says it leaves the control out of your readiness score and that auditors read the justification, so you must say why the control does not apply to your organization. "Bring back into scope" reverses it and removes the justification.

No false 100, no false zero. The score is a whole percentage. While anything in scope is not passing, the app holds it at 99 at most, so rounding cannot print 100 over a gap. A framework with nothing in scope scores 0 and is treated as not assessed, never as 100. When several frameworks are averaged on the Overview, the average also cannot read 100 unless every framework is at 100.

A worked illustration

The numbers below are an illustration, not customer data or a benchmark. Suppose a framework has 40 requirements on its Controls tab.

In scope: 40 minus 5 = 35. Passed: 14 + 5 + 2 = 21. Score: 21 divided by 35 = 60.

Now look at what each lever does. Scoping out five more requirements without real justification would lift the score to 70, and an auditor would read five weak justifications. Attesting the ten pending requirements with real evidence would lift it to about 89, and every attestation would carry a name and a description. Fixing the three scan failures would add three passes. Only the last two are real progress.

Read the coverage line, not just the number

Beside every score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation. In the app it reads like "X of Y controls evaluated automatically · A attested · Z need evidence or attestation", with an optional thin bar split into automated, attested and needs evidence. The code comment behind that line gives the reason in one sentence: a score alone cannot say whether 10% means ten percent of the framework is met or that the scan looked at a tenth of it. Always copy the coverage line with the score.

Step by step: switch on a framework and read its score

This walkthrough uses the screens named in Safeguard's documentation. Your plan decides which frameworks you can choose from, and your Safeguard administrator manages that list.

1. Make sure there is something to score. Scan requirements are checked "on each scan of a product". Connect at least one repository or upload an SBOM so a product has a scan and a software inventory. SBOM generation (GA), SCA (GA) and vulnerability management (GA) produce the inventory and findings the scan requirements read. If you want help choosing how Safeguard reaches your code, see our post on CLI or local runner.
2. Choose your frameworks. Open Compliance › Manage, then the Frameworks tab. Find a framework by region, country, industry or type, or search for it. Switch it on, then select Save. It appears on Compliance › Frameworks, Controls and Overview. Out of the box, every framework is on except national data-protection and cybersecurity laws, which start switched off; switch on the ones that apply to you. Choosing a framework does not certify anything.
3. Open the framework and read the score with its coverage line. On Compliance › Frameworks, open the framework. Note the score and the line beside it: how many controls were evaluated automatically, how many are attested, and how many need evidence or attestation.
4. Separate scan-evaluated requirements from evidence requirements. On the framework's Controls tab, scan requirements appear as controls. Use the framework's docs page as your key: it marks each requirement Scan, "Scan, then evidence" or Evidence, and says what Safeguard checks. Start with the failing scan-decided ones; they are usually software inventory facts you can fix.
5. Fix scan failures at the source. A failing scan requirement is about the product, not the paperwork: a component with no supplier, no exact version, no package URL, a missing hash, or an unremediated vulnerability. Fix the SBOM data or the dependency, then rescan. For vulnerable dependencies, autonomous remediation (GA) can open fix pull requests; it ships switched off, with every category set to Manual.
6. Connect systems for the controls automated tests can cover. On Compliance › Connectors, connect your identity provider, cloud accounts and code host where a live connector exists. Their tests evidence controls such as access management. If a connector you need is not live, use Request integration on the same screen. See continuous compliance in Safeguard for how tests run and why a new test may show results before it moves any control.
7. Start missing policies from templates. On the framework's Policies tab, select New policy and choose Start from template. Edit it, then Submit for review. Once a reviewer approves it, it is in force with a review date one year out, and it can evidence the controls it maps to that no automation judges.
8. Attest an evidence-only requirement. Open the control. Attach the evidence on its evidence panel (a document, link, screenshot or attestation), then, as a compliance reviewer, choose Attest and fill in What you reviewed: name the document, its version and date, and why it satisfies the control. Select Record attestation. The score updates when you save.
9. Accept submitted evidence. Evidence on Compliance › Evidence starts as submitted. A reviewer chooses Accept or Reject, and the decision is stamped with who, when and why. Results recorded by an automated test from its own run start accepted on that basis. Changing accepted evidence creates a new version that goes back to submitted.
10. Scope out only what truly does not apply. On the control, use Mark not applicable and write a justification an auditor would accept. The dialog's own example shows the kind of reasoning to write: the absence of the thing the control governs, for instance no data centres of your own, with your hosting provider's audit report as support.
11. Recheck the score and keep the record. Re-read the score and coverage line, and note the date, the products in scope and the last scan date. That record, not the number alone, is what you report.

Safeguard's AI assistant and MCP clients such as Claude can read your programme and prepare changes within your role's access, but under the approvals rules they never accept, approve, launch or acknowledge anything. Attestation and acceptance stay with people. The approvals documentation and our sibling post on approvals cover who counts as a reviewer.

Why the score moves after a scan, even when your controls did not change

Compliance leads are often surprised when a score drops overnight and nobody touched a policy. Almost always, the cause is in the software, because scan requirements are re-evaluated "on each scan of a product".

A new component arrived without the data a requirement needs. A developer adds a dependency whose metadata lacks a supplier, an exact version or a package URL. The next scan sees it, and the SSDF requirements for supplier identification (PW.4.1), precise identifiers (PW.4.4) and exact versions for advisory matching (RV.1.1) fail. The SOC 2 "Scan, then evidence" criteria that rely on a complete, versioned inventory (CC6.1, CC7.2) can fail on the same prerequisite. Your controls are the same; your inventory got worse.

A new vulnerability was published. A component you have shipped for a year gains a CVE. Requirements about identifying and managing vulnerabilities, such as SOC 2 CC7.1, can flip from met to not met with no change on your side.

Hashes or provenance went missing. A new build path produces artifacts without integrity hashes, and the release integrity check (PS.2.1 in SSDF terms; CC6.8 and PI1.5 prerequisites in SOC 2 terms) fails.

A mapped automated test failed or stopped running. A connected system changed (an account without MFA, a revoked token). A failing test fails the control; a test that errors or goes stale makes the control unproven, and an earlier pass stops counting.

Evidence expired or changed. Accepted evidence with an end date becomes expiring inside its reminder window and expired from that date. Editing accepted evidence creates a new version that goes back to submitted, so it stops counting until someone accepts it again.

An approved policy passed its review date. A policy only evidences a control while it is in force with its review date not passed. Miss the annual review and the controls it was carrying go back to needing evidence.

Someone brought a requirement back into scope. "Bring back into scope" adds it back to the denominator, usually as not yet passing.

The score can also rise for reasons that are not progress: a product dropped out of scanning, or a requirement was scoped out. That is why the coverage line and the scan date belong in every report.

If you suspect a component change, the companion posts in this series show how to check it: how Safeguard data is structured and portfolio sweeps and blast radius.

How to present the score to a board or an auditor

A readiness number travels. Once it is on a slide, people quote it without the context. Write the context into the number.

For a board

Use one sentence that carries the scope, the basis and the caveat. For example:

SOC 2 readiness in Safeguard is 62% as of 24 October, across the three products we scan. Of the criteria in scope, 9% are checked automatically by scans and connected-system tests, 41% have attested evidence, and the rest are waiting for evidence. This is our own internal measure, not an auditor's opinion.

The numbers in that example are illustrative. The structure is what matters: date, scope, the split between automated and attested, what is still open, and who owns the statement. Boards respond well to trend lines; if you show one, keep the same scope for every point, and flag any week where the scope changed.

Avoid three phrasings: "we are 62% SOC 2 compliant", "62% of the audit is done", and "Safeguard rates us 62%". The first is wrong about what compliance is, the second implies an auditor's progress, and the third makes the tool sound like an assessor.

For an auditor

An auditor will not accept a percentage as evidence of anything. Give them what sits behind it instead:

• The list of controls in scope, and the scoped-out list with each justification.
• For scan-decided requirements, the scan date and the products scanned, and the inventory or findings behind each result.
• For attested requirements, the attestation text, who made it and when, and the evidence it names.
• For accepted evidence, the version, who accepted it and when.
• For automated tests, the test, the resources it covered, approved exclusions with their reasons, approvers and expiry dates.

Expect the auditor to sample and re-perform. If a control is attested, they will want to see the underlying document and may test whether the activity really happened throughout the period. That is their job, and the decision trail the suite keeps makes it faster, not unnecessary. Our compliance reporting guide covers exports.

For a customer

If a customer asks for your SOC 2 status, give them your real status: report, scope and period if you have one; "in preparation" if you do not. Do not send a readiness screenshot as a substitute. If you publish posture to customers, the Trust Center is the place, and what you publish there is your own statement, not something the readiness score certifies.

What the score never means

It is not an audit opinion. Safeguard's docs say the score "is not an audit opinion or a certification". A CPA issues a SOC 2 opinion; an accredited certification body certifies an ISO/IEC 27001 management system.

It is not compliance. Many frameworks in the library are laws. Whether you comply with a law is a legal question that depends on facts outside any tool, including processing purposes, contracts and notifications.

It does not cover what Safeguard cannot see. Products you have not connected, systems with no live connector, paper processes and people's behaviour are invisible to scans and tests. A 100 on a framework says every in-scope requirement Safeguard tracks passes. It says nothing about products outside the scan or controls nobody mapped.

It does not prove operation over time. It is a count today. A control that passed today may have failed for three weeks in the spring.

It is not a maturity tier. It does not compute NIST CSF Tiers or a capability maturity level.

It does not certify the vendor. Nothing in your score is a statement about Safeguard's own compliance status, and nothing about Safeguard's status changes your score.

What Safeguard does not do

• It does not issue opinions or certificates. The suite helps you prepare and keeps a decision trail. A licensed CPA performs a SOC 2 examination; an accredited certification body audits an ISO/IEC 27001 ISMS. Safeguard does neither.
• It does not see outside its inputs. The score reflects scanned products and connected systems only. Roughly 50 evidence connectors are live today; others are available on request, and until one is connected its controls depend on uploaded evidence and attestations.
• It does not attest for you. Evidence-only requirements stay not yet passing until a compliance reviewer attests them with named evidence. The AI assistant and MCP clients can draft and submit, but they cannot accept, approve, launch or acknowledge.
• It does not judge your scoping. A person can scope out a requirement with any justification that meets the minimum length. Safeguard records it and shows it to auditors; it does not decide whether it is reasonable. Read every justification before you report the score.
• It does not choose your frameworks or plan. Your plan decides which frameworks appear, your administrator manages that list, and national laws start switched off. A framework you have not switched on has no score.
• It does not compute CSF Tiers, maturity levels or risk appetite. Those are your judgements.
• It does not automate every framework equally. Automated tests map directly to a small set of widely used frameworks. For most of the library, coverage is the scan requirements, catalogue controls and your own evidence.

Common mistakes

Comparing scores across frameworks. SOC 2 is mostly evidence; SSDF scan requirements are all scan-decided. A low SOC 2 number next to a high SSDF number is a description of the frameworks, not of your programme.

Reporting the score without the coverage line. "62%" and "62%, of which most is attested evidence" are very different statements. Always carry the split.

Scoping out to raise the number. It works on the dashboard and fails in the audit. Each justification is read. If a requirement applies but you have not done the work, leave it in scope and let the score be honest.

Setting controls to passing by hand. The score ignores it and the app flags it as needing review. Attest with evidence or leave it pending.

Writing thin attestations. "Reviewed, OK" names no evidence. Write the document, version, date and why it covers the control, as the form's placeholder shows.

Treating a scan pass as proof of the whole criterion. For "Scan, then evidence" requirements, the scan only checks a prerequisite. A complete inventory does not prove access control works.

Ignoring scan date and product scope. A score computed from a product last scanned two months ago is not current. State the date.

Forgetting expiry and review dates. Evidence expires and policies come due for annual review. A score that drops on a quiet week often means something ran out.

Presenting the score as the vendor's view of you. The score is your own management measure, computed by a tool. Say "our readiness in Safeguard", not "Safeguard rates us".

FAQ

What does the Safeguard readiness score measure?

The share of a framework's in-scope requirements that currently pass. A requirement passes on a scan or automated test that finds it met, on a compliance reviewer's attestation that names its evidence, or, where nothing automated judges it, on an approved policy in force that maps to it.

Is a 100% readiness score the same as being SOC 2 compliant?

No. SOC 2 is a report a CPA firm issues after examining your controls, and for a Type 2 the period they operated. A 100 means every in-scope requirement Safeguard tracks passes today. It is not an audit opinion or a certification, and it does not cover what Safeguard cannot see.

Why is my SOC 2 readiness score so low when my scans are clean?

Because SOC 2 in Safeguard is mostly evidence. On the SOC2 Type 1 page only CC7.1 is decided by a scan alone; a handful of criteria are "Scan, then evidence", and the rest need evidence. Connect systems for automated tests, start policies from templates, and attest the evidence-only criteria.

Why did my readiness score drop when nothing changed?

Something in the software or in the evidence usually did. Typical causes: a new component without a supplier, version or package URL; a newly published vulnerability; a mapped test that failed or stopped running; expired evidence; or a policy past its review date.

Do requirements waiting for evidence count against the score?

Yes. They stay in the denominator as not yet passing until a person attests them with evidence. Only scoping a requirement out, with a written justification, removes it from the score.

Can I attest a control that a scan or test is failing?

You can record an attestation, but it will not pass the control. In Safeguard, a failing scan verdict or failing automated test fails the control whatever was attested. Fix the cause, or ask for an approved exclusion for a specific resource with a reason, approver and expiry date.

Can Claude or Safeguard's AI assistant attest requirements or accept evidence?

No. Safeguard's approvals rules say the assistant and MCP clients can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in behind them. Attestation in the app is done by a compliance reviewer.

What is the difference between "Scan" and "Scan, then evidence"?

"Scan" means the scan decides met or not met. "Scan, then evidence" means the scan checks a prerequisite, such as a complete component inventory, and fails the requirement if it is missing; only evidence or an attestation can pass it.

Should I show the readiness score to my auditor?

Show it as context, with its coverage line, scope and date. Then give the auditor the records behind it: attestations, accepted evidence, test results, exclusions and scope justifications. The auditor tests those; the number itself is not evidence.

Does the readiness score appear on my Trust Center?

The Trust Center is where you choose what to publish about your posture to customers. What you publish there is your own statement. Do not present a readiness score to customers as an audit result.

From a failing scan requirement to a fix

Many scan-decided requirements fail for one plain reason: a vulnerable or poorly described component is still in a product you ship. Fixing that component is the fastest honest way to move a readiness score, and the options below are how Safeguard helps you do it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. Add Safeguard from Claude's connector directory, where it is a community listing, rather than configuring a custom connector. Where your tenant's tools include your programme data, an assistant can help you list the requirements still waiting for evidence or draft the board sentence above, but it cannot attest a requirement or accept evidence; that stays with a compliance reviewer in the app.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the desktop app. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. When a scan-decided requirement is failing because of a vulnerable dependency, this is the approve each step flow that gets the fix in; the next scan then re-evaluates the requirement and the score.

Click through it at your own pace, or open it full screen.

To try it on your own products, download the apps at safeguard.sh/download and read the setup guides at docs.safeguard.sh. For related reading, see mapping one control to many frameworks, SOC 2 control mapping with supply chain evidence and a compliance lead's day in Safeguard.

Quick check

Sources

• Safeguard docs: Compliance frameworks (coverage model, readiness score, choosing frameworks, templates)
• Safeguard docs: Compliance
• Safeguard docs: All frameworks
• Safeguard docs: SOC2 Type 1 framework page
• Safeguard docs: NIST SSDF framework page
• Safeguard docs: Approvals
• AICPA: SOC 2 Reporting on an Examination of Controls at a Service Organization (guide page)
• AICPA: System and Organization Controls, SOC suite of services
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• NIST Cybersecurity Framework
• NIST SP 800-53A Rev. 5 publication page
• NIST SP 800-53A Rev. 5 (PDF)
• NIST SP 800-218, Secure Software Development Framework v1.1 (PDF)
• NTIA: The Minimum Elements for a Software Bill of Materials (July 2021)
• The IIA: The Three Lines Model, an update of the Three Lines of Defense

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.