The Compliance Risk Register in Safeguard: Score, Treat, Accept

Safeguard keeps the compliance risk register on Compliance › Risks, inside the Compliance and GRC suite (GA). Who may accept a risk depends on its residual level: the risk owner can accept a low or medium residual risk, recorded with their name and reason, while a high or critical one needs an approver with an admin role and a review date within a year. If the residual risk later rises above the level it was accepted at, the acceptance shows "Needs re-approval".

The rest of the register is method, and the method is yours. This post explains what ISO/IEC 27001, SOC 2, the HIPAA Security Rule and NIST CSF 2.0 expect of a register, how to score and treat risks using NIST SP 800-30, SP 800-39 and ISO 31000 as general practice, and how the documented parts of Safeguard (risk acceptance, approvals, evidence, mitigations, crosswalks and TPRM) carry those decisions into an audit trail.

Key takeaways

• Compliance and GRC suite (GA). The suite's areas include Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center (GA) and Connectors. The register lives under Risks.
• Acceptance scales with the residual level. Low or medium: the risk owner accepts, recorded with their name and reason. High or critical: an approver with an admin role, plus a date to review it within a year.
• "Needs re-approval." When residual risk rises above the level it was accepted at, a person must re-approve or revoke the acceptance.
• Assistants never decide. Safeguard's AI assistant and MCP clients such as Claude or ChatGPT can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in.
• Findings stay findings first. A vulnerability that does not affect you belongs in a VEX statement (CSAF and VEX upload, GA) or a project mitigation under vulnerability management (GA). The register is for risk that outlives one advisory.
• Prioritisation feeds scoring. Reachability analysis (GA) with EPSS and KEV enrichment gives you likelihood inputs for software risk. Impact comes from you.
• Supplier risk comes in through TPRM (GA): supplier SBOM requests, risk scoring and continuous monitoring.
• The method is yours. Scales, appetite, treatment choices and the decision to accept are management decisions. Safeguard records them; it does not make them.

What the standards ask of a risk register

No major framework mandates a spreadsheet called a risk register. They all ask for the same underlying things: a defined method, named owners, a treatment decision, a record of who accepted what is left, and a review cycle. A register is the usual way to show all of that in one place.

ISO/IEC 27001:2022 and ISO/IEC 27005:2022

ISO/IEC 27001:2022 sets the requirements for an information security management system, and ISO's own summary describes the standard as a tool for risk management. In general terms, clause 6.1.2 covers information security risk assessment, clause 6.1.3 covers risk treatment (which leads to the Statement of Applicability and a treatment plan), and clauses 8.2 and 8.3 cover performing those assessments and treatments in operation and keeping the results. An auditor will look for defined criteria, named risk owners, a treatment decision for each risk, and evidence that the owners accepted what remained.

ISO/IEC 27005:2022 is ISO's guidance on managing information security risks for a 27001 ISMS. ISO describes it as adapting the general principles of ISO 31000 to information security and covering the full cycle: assessment, treatment, communication, monitoring and review.

ISO 31000:2018

ISO 31000 provides principles and guidelines for risk management. ISO's page describes its approach as identifying, analysing, evaluating, treating, monitoring and communicating risks across an organisation, and notes that it cannot be used for certification. It is the vocabulary most risk teams share, and it is the right frame for a register: each entry should show where it is in that cycle.

SOC 2: the CC3 risk assessment criteria

The AICPA's 2017 Trust Services Criteria, with points of focus revised in 2022, place risk assessment in the CC3 series of the common criteria that every SOC 2 report covers. In general terms, CC3.1 to CC3.4 deal with setting objectives clearly enough to assess risk, identifying and analysing risks, considering fraud, and assessing significant changes. A SOC 2 auditor tests that the process ran during the period under review, not just that a register exists at the end of it.

HIPAA Security Rule: 164.308(a)(1)(ii)(A) and (B)

The HIPAA Security Rule makes both risk analysis and risk management required implementation specifications. Under 45 CFR 164.308(a)(1)(ii)(A), risk analysis means an "accurate and thorough assessment" of the potential risks and vulnerabilities to electronic protected health information. Under (B), risk management means implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

HHS's guidance on risk analysis adds three practical points. Organisations must identify and document reasonably anticipated threats and vulnerabilities. They must take into account the probability of potential risks. And the process should be ongoing, with the risk analysis documentation serving as a direct input to risk management. That is a register in all but name. See HIPAA risk analysis versus risk management.

NIST CSF 2.0: GV.RM, ID.RA and GV.OV

The NIST Cybersecurity Framework 2.0 (CSWP 29) moved risk strategy into the Govern function:

• GV.RM-02 asks that risk appetite and risk tolerance statements be established, communicated and maintained.
• GV.RM-04 asks for strategic direction describing appropriate risk response options.
• GV.RM-06 asks for "a standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks".

On the Identify side, ID.RA-05 uses threats, vulnerabilities, likelihoods and impacts to understand inherent risk and prioritise responses; ID.RA-06 says risk responses are chosen, prioritised, planned, tracked and communicated; and ID.RA-07 says changes and exceptions are managed, assessed for risk impact, recorded and tracked. GV.OV-03 asks that risk management performance be evaluated and reviewed.

NIST SP 800-30 and SP 800-39

NIST SP 800-30 Rev. 1 is the standard US guide to conducting risk assessments. It treats risk as a function of the likelihood of a threat event and its potential impact, and allows qualitative, quantitative or semi-quantitative scales. NIST SP 800-39 places assessment inside a wider cycle of four components: frame risk, assess it, respond to it, and monitor it over time. Its list of responses (acceptance, avoidance, mitigation, sharing or transfer) is the one most registers use.

The next two sections draw on both documents as general practice. They describe how to run a register well, not how Safeguard computes anything.

Scoring a risk: general practice

Safeguard's documented acceptance rules turn on one thing: the residual risk level, low, medium, high or critical. How you arrive at that level is your methodology. Here is a defensible way to build one.

Score likelihood and impact separately

SP 800-30 assesses likelihood and impact on separate scales, then combines them. Its example scales have five qualitative values, Very Low to Very High, each with a semi-quantitative equivalent. For impact (Table H-3), "High" means a threat event could be expected to have a severe or catastrophic adverse effect, for example major financial loss or the inability to perform a primary function. "Moderate" means a serious adverse effect, such as significant degradation of a function that still runs.

Write your own definitions for each level, in money, downtime, records exposed or regulatory consequence. "Severe" for a ten-person startup and "Severe" for a bank are different sums. Without written definitions, two assessors will score the same risk differently, and GV.RM-06's "standardized method" is not met.

Combine them with a matrix you can defend

SP 800-30 Table I-2 combines the two into a level of risk. A shortened view of NIST's example:

Two things stand out. First, the matrix is not symmetric: a very high impact keeps the risk at least moderate even at low likelihood. Second, reducing likelihood alone often leaves a high-impact risk high. Treatment that lowers impact (segmentation, backups, data minimisation) is frequently what moves a risk down a level.

Safeguard's acceptance rules use four levels: low, medium, high and critical. If your matrix has five levels, write down how they map (for example Very Low and Low to low, Moderate to medium, High to high, Very High to critical) and apply it every time.

Know what a score is not

SP 800-30's semi-quantitative values (for example 96 to 100 for Very High risk, 80 to 95 for High) are ranks, not measurements. A risk scored 20 on a 5 by 5 grid is not "twice" a risk scored 10, and adding scores across a register means nothing. Use scores to sort and to set levels. Use words and money to explain them.

Inherent and residual

Inherent risk is the level before the specific controls that treat this risk. Residual risk is what remains after treatment. CSF 2.0 ID.RA-05 asks you to understand inherent risk to prioritise responses; acceptance decisions, in ISO 27001 and in Safeguard, are about the residual.

The trap is a residual that someone simply typed lower. A good register says why the residual is lower: which controls, tested how, with what evidence. If you cannot point to the control and its evidence, the residual equals the inherent level.

Worked example (illustrative)

Take an illustrative risk: "A known exploited vulnerability in a third-party library used by the billing service stays unpatched past our remediation window, exposing card data."

• Inherent. Likelihood High (the vulnerability is on CISA's KEV list and reachable), impact Very High (cardholder data and a regulatory reporting duty). Table I-2 gives Very High. Mapped to Safeguard's levels: critical.
• Treatment A: mitigate likelihood only. A patch SLA, a gate that blocks new builds with known exploited vulnerabilities, and weekly review lower likelihood to Moderate. Impact stays Very High. Table I-2 gives High. Acceptance would still need an admin approver and a review date.
• Treatment B: also lower impact. Move card data behind a tokenisation service so the billing service never holds it. Impact drops to High. With Moderate likelihood, Table I-2 gives Moderate: medium. The owner can now accept the residual, recorded with their name and reason.

The example shows why it pays to treat impact, and why a register that only tracks patching rarely gets a severe risk below high.

Choosing a treatment: general practice

SP 800-39 describes four responses. Each needs different evidence.

Two nuances matter.

Transfer does not make the event less likely. SP 800-39 says plainly that transfer reduces neither the likelihood of harmful events nor their consequences; it moves who pays. Insurance can reduce the financial impact to you, but not the harm to customers. If you lower a score for transfer, write down which impact you lowered and why.

Acceptance does not reduce risk. SP 800-39 notes that organisations may accept low, moderate or even high risk when there is a compelling business need, but acceptance is a decision about tolerance, not a treatment that changes the level. That is why Safeguard asks for more authority, not less paperwork, as the accepted level rises.

ISO 31000's cycle adds one more expectation: treatment is not finished when it is chosen. Monitor whether it worked, and reassess.

Step by step: run a risk through Safeguard

Safeguard's docs describe the acceptance and approval mechanics of the Risks area; they do not publish a field-by-field guide to recording a risk. The steps below follow the documented flow and describe outcomes rather than inventing screens. Your plan and role decide whether you see the Risks area; if you do not, ask your Safeguard administrator.

1. Agree your method first. Before the first entry, write your scales, matrix, mapping to low, medium, high and critical, and who may accept at each level. Start the document from the Risk Assessment and Management Policy template, one of the standard policy templates every framework in Safeguard's library has. Open the framework on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template.
2. Get the method approved. On Compliance › Policies, send it with Submit for review. A compliance reviewer approves it. The effective date defaults to the approval day and the next review to one year later. Editing it later sends a new version to review while the approved one stays in force.
3. Record the risk on Compliance › Risks. Capture a risk statement (cause, event, consequence), the owner, your inherent assessment and the treatment you chose. Name the controls that treat it, so a reviewer can follow the thread.
4. Build the evidence behind the treatment. The controls you named live on Compliance › Controls. Evidence for them goes on Compliance › Evidence: it starts as submitted, and a reviewer chooses Accept or Reject, stamped with who, when and why. A result recorded by an automated test from its own run starts accepted on that basis. Accepted evidence with an end date becomes expiring inside its reminder window and expired from that date.
5. Reassess the residual. Once the controls are in place and evidenced, record the residual level. Use the same method as the inherent assessment.
6. Accept a low or medium residual risk as owner. The risk owner can accept it, and it is recorded with their name and reason.
7. Route a high or critical residual risk to an admin approver. Acceptance needs an approver with an admin role, and a date to review it within a year.
8. Watch for "Needs re-approval". If the residual later rises above the level it was accepted at, the acceptance shows Needs re-approval. Re-approve it or revoke it.
9. Let assistants draft, not decide. Safeguard's AI assistant and MCP clients can prepare the risk statement or a justification, but cannot accept or approve. A write from an MCP client runs only after you confirm it in that client, and even a confirmed write cannot accept a risk.
10. Review on a schedule. Your method sets the cadence. Higher residual levels deserve shorter cycles; the one-year review date for high or critical acceptances is the outer limit, not the target.

What "Needs re-approval" means and how to respond

An acceptance is made at a level. Safeguard's docs say that if the residual risk later rises above the level it was accepted at, the acceptance shows Needs re-approval, and the choice is to re-approve or revoke.

Residual risk rises for ordinary reasons: a control that treated the risk starts failing, the evidence behind it expires or is rejected, or new information (a supplier incident, a new data type in the system) prompts a reassessment. In general practice, respond like this:

1. Find what changed. Check the controls you named in the risk, their tests on Compliance › Tests, and their evidence on Compliance › Evidence.
2. Decide whether the change is real. If a test is failing because a connected account was misconfigured, fix the cause and re-run the test.
3. Make a new decision. If the risk really is higher, re-approve at the new level, which for high or critical needs an admin approver and a review date within a year, or revoke the acceptance and move the risk back into treatment.
4. Record why. An auditor will ask why a stale acceptance stayed in place, and "nobody looked" is the wrong answer.

The flag is what CSF 2.0 ID.RA-07 and GV.OV-03 ask for in practice: noticing that the facts behind a decision changed and putting the decision back in front of a person. For the wider approvals model, see who approves what in Safeguard compliance.

How a software finding becomes a register entry, and when it should not

Teams get this wrong both ways: every high CVE becomes a register entry and the register drowns, or no software risk reaches it and the board never hears about a dependency that matters. Safeguard has three places for three questions.

1. "This CVE does not affect us": VEX

If a vulnerability is in your inventory but not exploitable in your product, that is a statement of fact about the product, and the format for it is VEX. CISA's minimum requirements for VEX say a "not_affected" status should carry a justification such as "Component_not_present", and if it does not, it must carry an impact statement. Safeguard's CSAF and VEX upload (GA) takes those documents in. See ingest and share VEX and CSAF in Safeguard.

2. "This CVE affects one project and we are handling it": a project mitigation

For a specific vulnerability in a specific project, Safeguard's vulnerability management (GA) has a Mitigations tab on each project. Safeguard's docs describe four types: Risk Acceptance, False Positive, Workaround Applied and Not Applicable. The form asks for a type, a justification, who approved it and a scope (this version only, or all versions), with an optional expiration date for a risk acceptance and optional evidence. A mitigation is Active, Expired, Revoked or Superseded, and each action is logged with who, when and why.

Mitigations interact with gates. Per the docs, active mitigations exclude a vulnerability from gate failures, and expired ones do not, so the expiry date is a real control: when a finding-level acceptance lapses, the gate starts failing again. The docs also describe mitigation policies that apply automatically, for example by CVE, by package or below a severity threshold. Use those sparingly, because an auto-applied acceptance never reaches a person. The mitigations docs page carries a banner that its /v1 REST endpoints are not yet available, so use the in-app flow.

3. "This is a business risk that outlives one CVE": the register

A register entry is right when the risk is about your organisation's exposure, not a single finding. Signals:

• It recurs. The same component, or the same class of weakness, keeps producing findings across many projects. The risk is "we depend on a library we cannot patch quickly", not one CVE.
• There is no fix. The vulnerability is reachable, it matters, and upstream has not shipped a fix. The decision is a business one: compensating control, removal, or a time-boxed acceptance.
• It passes a remediation SLA. CISA's Known Exploited Vulnerabilities catalog is the authoritative list of vulnerabilities exploited in the wild, so a KEV entry still open past your window deserves a named owner and an acceptance decision.
• A supplier is the source. A third party's software carries the risk and you cannot change it directly. TPRM (GA) is where you request SBOMs from that supplier, score their risk and monitor them for new vulnerabilities; the register entry records your decision about what remains. See supplier software risk under DORA, NIS2 and M-22-18 with Safeguard TPRM.

Use the finding data to score the entry. Safeguard's prioritisation gives you most of the likelihood inputs: reachability, EPSS and KEV status. FIRST describes EPSS as an estimate of the probability that a published CVE will be exploited in the wild in the next 30 days. A reachable, KEV-listed vulnerability with a high EPSS score is High or Very High likelihood by most definitions; an unreachable one with no exploitation evidence is not. Impact comes from what the affected system does, which only you know. See prioritise vulnerabilities with reachability, EPSS and KEV, dependency vulnerabilities in your risk register and CVSS vs EPSS vs KEV.

How the register connects to controls and evidence for an auditor

An auditor wants to follow a thread: risk, treatment, control, evidence, decision. In Safeguard, each link in that thread lives in a documented part of the suite.

• Risk and decision. Compliance › Risks holds the risk and its acceptance, recorded with who accepted it and why, and for high or critical levels, the admin approver and review date.
• Controls. A framework's scan requirements appear as controls on its Controls tab, and for many frameworks Safeguard's control catalogue adds more controls that you evidence with automated tests, uploaded evidence, policies and attestations.
• Tests. Systems you connect run automated tests that map to the controls of SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, and to the CIS benchmarks.
• Evidence. Each piece is submitted, then accepted or rejected by a reviewer. Changing accepted evidence makes a new version that goes back to submitted, because an acceptance covers the version the reviewer saw.
• Policies. Your risk methodology, approved as one version with a review date.

The crosswalk lets one piece of evidence serve several frameworks. On Compliance › Crosswalk, a reviewer decides whether a mapping between two frameworks' controls holds for your programme: Approve, Reject or Withdraw decision. Approving an equivalent mapping makes accepted evidence for the source control count toward the target control; approving a partial mapping confirms the suggestion but makes nothing count. Decisions are never edited or deleted, so the history stays readable. See map one control to many frameworks.

For ISO/IEC 27001, the register feeds your Statement of Applicability: the controls you choose to treat risks are the ones you justify including. See ISO 27001:2022 in Safeguard. For HIPAA, see HIPAA Security Rule in Safeguard.

Exception register versus risk register, and where test exclusions fit

An exception is a decision not to apply a control to something; a risk is a possible event and its consequences. One exception can create a risk. Many risks have no exception at all.

In Safeguard, exceptions to automated tests are test exclusions. On a test's detail page under Compliance › Tests, Exclude asks to exclude one resource from that test, such as a break-glass account. You give a Reason, choose an Approver and set Expires on. Nothing is excluded until the approver approves it; from then until expiry, the resource counts as not applicable, with your reason shown as the evidence. An exclusion is Pending approval, Approved, Rejected, Revoked or Expired, and the Exclusions tab lists them.

A sensible pattern: when an exclusion covers something material (an admin account without multi-factor authentication, say), add a register entry for the risk it creates and name the control the exclusion touches. CSF 2.0 ID.RA-07 asks for exactly that: exceptions assessed for risk impact, recorded and tracked. See exception register vs risk register.

Reporting the register to leadership without false precision

What to show:

• Counts by residual level, not averages. "Three critical, eleven high" is honest. "Average risk 8.4" is not.
• Accepted high or critical risks, by name, owner and review date. These are the risks the organisation chose to live with, and the list the board should see.
• Acceptances that need re-approval. Each is a decision that no longer matches the facts.
• Reviews overdue. A register nobody reviews is a historical document.
• Movement since last quarter, with the reason. "Two high risks fell to medium because card data moved behind tokenisation" beats any percentage.
• The method, in one paragraph, so leadership knows what "high" means.

Avoid heat maps without counts, trends built from risks re-scored under different definitions, and any claim that the register covers systems you have not connected or scanned. For framing the same data for different audiences, see one dataset, four audiences.

Using an assistant with the register

Safeguard's AI assistant and MCP clients such as Claude or ChatGPT can read your programme and prepare changes within the access your workspace and role allow. That makes them useful for the drafting around a register: a first risk statement from a finding, a list of risks whose acceptances need re-approval, or a first justification for a person to edit. The decision stays with a person in the app. Add Safeguard to Claude from the connector directory, where it is a community listing, rather than setting up a custom connection; which tools appear depends on your plan and your administrator's settings. For turning findings into a ranked fix list, see what to fix first.

Decision table: requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not set your risk appetite or methodology. Scales, matrix, level definitions and who may accept beyond the documented minimums are your decisions, written in your own policy. GV.RM-02 asks you for appetite statements; Safeguard does not write them.
• It does not discover business risks. The register holds what people put in it. Scans find vulnerabilities and tests find misconfigurations, but "single supplier for payroll" or "key person dependency" comes from your own assessment.
• It does not turn findings into register entries for you. A person decides which findings rise to business risk. That keeps the register meaningful, but someone has to do the triage.
• Scores are inputs, not decisions. A residual level tells you who may accept. It does not tell you whether to accept. An accepted risk is still a risk.
• It does not audit or certify. Your register, decisions and evidence are what an auditor tests. Safeguard does not issue an opinion, and choosing a framework does not certify compliance.
• It does not see what you have not connected or scanned. Tests and evidence cover only the systems you connect and the products you scan. Some connectors are available only on request, so check what is live for your plan.
• Assistants never accept risk. Neither Safeguard's assistant nor any MCP client can accept, approve or revoke an acceptance.

Common mistakes

Typing the residual instead of earning it. If you cannot name the control and its evidence, the residual equals the inherent level.

Scoring impact as "how bad is the CVE". CVSS describes the vulnerability, not your business. A critical CVE in an internal build tool may be a moderate business impact; a medium CVE in the system holding health records may be severe.

Treating only likelihood. Patching and gates lower likelihood. Severe impacts usually need design changes to move.

One register entry per CVE. Findings belong in vulnerability management, with mitigations and VEX. The register is for risks that outlive one advisory.

Accepting with a vague reason. "Business decision" is not a justification. Say why the risk is accepted, what limits it, and what would change the decision.

Ignoring "Needs re-approval". A stale acceptance accepts a risk nobody actually accepted.

Auto-applying mitigations broadly. A severity-threshold policy can quietly accept findings nobody reviewed.

Letting reviews lapse. A register full of overdue reviews tells an auditor the process is not running.

FAQ

Who can accept a risk in Safeguard?

The risk owner can accept a low or medium residual risk, recorded with their name and reason. A high or critical residual risk needs an approver with an admin role and a date to review it within a year.

What does "Needs re-approval" mean on a Safeguard risk?

The residual risk has risen above the level it was accepted at. A person must re-approve the acceptance at the new level or revoke it.

What is the difference between inherent and residual risk?

Inherent risk is the level before the specific controls that treat the risk. Residual risk is what remains after treatment. Acceptance decisions, in ISO/IEC 27001 and in Safeguard, are about the residual.

How should I score likelihood and impact?

Use separate written scales for each, then combine them with a matrix such as NIST SP 800-30 Table I-2. Define every level in your own terms (money, downtime, records, regulatory consequence) and map the result to low, medium, high and critical.

Should every critical vulnerability go into the risk register?

No. Handle findings in vulnerability management, with project mitigations or VEX statements. Add a register entry when the risk outlives one finding: it recurs, has no fix, has passed your remediation window, or comes from a supplier you cannot change.

Is a test exclusion the same as a risk acceptance?

No. A test exclusion removes one resource from one automated test, with a reason, an approver and an expiry date. A risk acceptance is a decision to live with the residual of a whole risk. A material exclusion often deserves its own register entry.

Can Claude or ChatGPT accept a risk through the Safeguard connector?

No. Safeguard's assistant and MCP clients can read and draft, and a write runs only after you confirm it, but they can never accept, approve, launch or acknowledge anything.

Does a risk register satisfy the HIPAA risk analysis requirement?

It is part of it. The register records risks, treatments and decisions; 164.308(a)(1)(ii)(A) still requires an accurate and thorough assessment across all ePHI, including people, facilities and paper processes Safeguard does not see.

Fewer risks to accept

The cheapest risk to accept is the one you never have to. Much of the software risk that reaches a register starts as a known vulnerability that lingered, so shortening the time to a fix keeps entries out of the high and critical levels in the first place.

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, Safeguard's Griffin models open 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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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 shows Claude being connected to Safeguard with an OAuth sign-in and choosing which tools Claude may use. For a risk register, that is the setup behind asking Claude which acceptances need re-approval or drafting a risk statement from a finding; the acceptance itself stays with a person in the app. In practice, add Safeguard from Claude's connector directory rather than setting up a custom connection.

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

The second demo is a real Android session in the Safeguard mobile app: work is sent to a computer running the Safeguard CLI (GA), and the person approves the command on the phone with Allow once, Allow for turn or Deny. It is a different surface from the register, but it shows the principle behind risk acceptance: the agent proposes, and a named person decides.

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

For the day-to-day view of a compliance programme in the suite, see continuous compliance in Safeguard. For a lighter starting point, see risk register template fields for a small team.

To try it, download the apps at safeguard.sh/download and read the documentation at docs.safeguard.sh.

Quick check

Sources

• Safeguard docs: Approvals
• Safeguard docs: Requests and approvals
• Safeguard docs: Compliance frameworks
• Safeguard docs: Compliance
• Safeguard docs: Mitigations
• Safeguard docs: Third Party Risk Manager
• ISO/IEC 27001:2022, Information security management systems, Requirements
• ISO/IEC 27005:2022, Guidance on managing information security risks
• ISO 31000:2018, Risk management, Guidelines
• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• eCFR: 45 CFR 164.308, Administrative safeguards
• HHS: Guidance on Risk Analysis
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
• NIST SP 800-39: Managing Information Security Risk
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• FIRST: Exploit Prediction Scoring System (EPSS)
• CISA: Known Exploited Vulnerabilities Catalog

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