Continuous Compliance in Safeguard: Controls, Evidence and Tests

Continuous compliance in Safeguard means your controls are checked on a schedule, not once a year. The compliance and GRC suite (GA) maps each control to every framework that needs it, runs automated tests against the systems you connect, and keeps accepted evidence in date. Auditors then test that record instead of a folder of fresh screenshots.

That is the short answer. The rest of this post explains why the standards push teams toward ongoing monitoring, how the suite is laid out, the real flow from switching on a framework to closing a failing control, and the honest limits. Safeguard does not perform your audit, does not issue a report and does not certify you. An independent auditor or certification body still does that.

Key takeaways

• The compliance and GRC suite is GA. Its areas are Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors and Connectors.
• Evidence connectors are GA, with an honest caveat: Safeguard says roughly 50 evidence connectors are live today, with more added on request. The docs catalogue is larger and labels what each connector actually produces, so check the card before you count on one.
• Evidence mapping by Lion, Safeguard's compliance model (the docs call it Lino), is GA. A person still accepts or rejects every piece of evidence.
• Automated tests map directly to SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, plus several CIS benchmarks. A reviewed crosswalk carries accepted evidence to equivalent controls in the other mapped frameworks, including NIST SP 800-53.
• Software supply chain output, such as SBOM generation (GA), policies and gates (GA) and attestation and signing (GA), feeds the same control record.
• The Trust Center is early access and switched on per workspace. It can show live control status to customers, but it is not an independent attestation.
• A readiness score is Safeguard's view of what it can see. The docs say plainly that it is not an audit opinion or a certification.

Why the once a year evidence sprint keeps failing

Most compliance programmes still run on a calendar. The audit window approaches, someone builds a spreadsheet of controls, and engineers spend two or three weeks taking screenshots of console settings, exporting user lists and hunting for the ticket that proves a change was approved. The auditor samples that pile. Everyone relaxes for eleven months.

Three things go wrong with that rhythm.

First, the evidence describes one moment. A screenshot of multi factor authentication settings proves the setting was on the afternoon it was taken. It says nothing about the week in March when an admin switched it off to debug a login problem and forgot to switch it back. Type 2 style reports and surveillance audits care about operation over a period, so point in time evidence leaves a gap you have to explain.

Second, the same work is done several times. A team that holds SOC 2, works toward ISO/IEC 27001 and handles health data for one customer under HIPAA is usually answering the same underlying question (are accounts reviewed, are logs kept, are vulnerabilities fixed) three times in three formats. Without a shared control record, each framework gets its own evidence folder and its own drift.

Third, problems surface late. If evidence is only gathered for the audit, a broken control is discovered by the auditor rather than by you. That turns a quiet fix into a finding.

Continuous compliance tries to fix all three: check controls on a schedule, store evidence once and reuse it across frameworks, and learn about a failing control while it is still cheap to fix. The standards themselves have been moving in that direction for years, which is the next section.

What the standards expect about ongoing monitoring and evidence

None of the major frameworks uses the words "continuous compliance" as a product category. What they do is require monitoring, evaluation and review at a frequency that matches the risk, and ask you to show that controls operated over time. Here is what the primary texts say.

AICPA Trust Services Criteria (SOC 2)

SOC 2 reports are built on the AICPA's 2017 Trust Services Criteria, which the AICPA republished with revised points of focus in 2022. The AICPA describes them as control criteria for attestation or consulting engagements that evaluate controls over security, availability, processing integrity, confidentiality or privacy.

The criteria follow the COSO internal control structure. The monitoring activities series (CC4) is the part that matters here: CC4.1 covers evaluations that confirm controls are present and functioning, and CC4.2 covers communicating deficiencies to the people who can fix them. The system operations series (CC7) adds detection and monitoring of security events and vulnerabilities.

The practical point for a SOC 2 Type 2 report is the period. The auditor tests whether controls operated throughout the review window, not on a single day. A record of scheduled test results, with dates and the evidence each one read, is easier to sample than a set of screenshots taken in the last fortnight.

ISO/IEC 27001:2022, clause 9 and Annex A

ISO/IEC 27001:2022 makes performance evaluation a management system requirement rather than an option. Clause 9 has three parts: 9.1 on monitoring, measurement, analysis and evaluation, 9.2 on internal audit, and 9.3 on management review. Clause 9.1 expects you to decide what is monitored and measured, how, when, and who analyses the results.

Annex A then lists the reference controls that your Statement of Applicability works from. Several of them are about ongoing checking rather than one time setup, for example A.8.8 on management of technical vulnerabilities, A.8.16 on monitoring activities, and A.5.36 on compliance with the organization's own policies and standards. Certification bodies run surveillance audits between recertifications, so drift between audits is something you are expected to catch yourself.

NIST Cybersecurity Framework 2.0

NIST published CSF 2.0 on 26 February 2024. It added a Govern function, and two of its categories speak directly to ongoing monitoring of the programme itself:

• Oversight (GV.OV) asks that results of risk management activities are used to inform, improve and adjust the strategy. GV.OV-03 asks that risk management performance is "evaluated and reviewed for adjustments needed."
• Improvement (ID.IM) asks that improvements are identified from evaluations (ID.IM-01) and from security tests and exercises (ID.IM-02).

The Detect function adds Continuous Monitoring (DE.CM), with subcategories for networks (DE.CM-01), personnel activity and technology usage (DE.CM-03), external service providers (DE.CM-06) and computing hardware, software and runtime environments (DE.CM-09). CSF 2.0 also uses Current and Target Organizational Profiles, and expects you to analyse the gap between them and keep the profile updated as you act on it. A control record that updates itself is a reasonable way to keep a Current Profile honest.

CSF 2.0 also brings supply chain into governance through the GV.SC category, for example GV.SC-04 (suppliers are known and prioritized by criticality). That matters later in this post, when software supply chain findings become evidence.

NIST SP 800-53 Rev. 5, CA-7, and SP 800-137

For teams under federal or federally derived programmes, control CA-7 in NIST SP 800-53 Rev. 5 (September 2020) is the clearest statement of what continuous monitoring means. It asks for a system level monitoring strategy that includes:

• organization defined metrics to monitor;
• organization defined frequencies for monitoring and for assessing control effectiveness;
• ongoing control assessments and ongoing monitoring of those metrics;
• correlation and analysis of what the assessments and monitoring produce;
• response actions based on that analysis; and
• reporting security and privacy status to named roles at a set frequency.

The discussion text makes a useful point: "continuous" and "ongoing" mean often enough to support risk decisions, and different controls may need different frequencies. Continuous does not mean every second.

NIST SP 800-137 (September 2011), the guide to information security continuous monitoring, defines ISCM as "maintaining ongoing awareness of information security, vulnerabilities, and threats" to support risk decisions. Both documents describe a loop: define, monitor, analyse, respond, report, repeat.

HIPAA Security Rule, 45 CFR 164.308

The HIPAA Security Rule's administrative safeguards set two expectations that fit here. Under 164.308(a)(1)(ii)(D), information system activity review is a required implementation specification: you implement procedures to regularly review records such as audit logs, access reports and security incident tracking reports. Under 164.308(a)(8), the Evaluation standard asks for a periodic technical and nontechnical evaluation, repeated when environmental or operational changes affect the security of electronic protected health information.

The rule does not set a fixed frequency. "Regularly" and "periodic" are yours to define and defend, which is exactly why a dated record of checks helps.

PCI DSS v4.0.1

The PCI Security Standards Council lists PCI DSS v4.0.1 as the current version in its document library, alongside a summary of changes from v4.0. PCI DSS is more prescriptive than the frameworks above and sets specific frequencies for many recurring activities, including log review and vulnerability scanning. Read the requirement text in the standard itself for your exact obligations; this post does not restate requirement numbers we could not check against the published text.

What the frameworks have in common

The shared shape is clear. Define what you check and how often, check it, record the result, fix what fails, and be able to show the history. That is the job the Safeguard suite is built around.

The areas of the Safeguard compliance suite

The compliance and GRC suite (GA) lives under Compliance in the Safeguard web app. The offering describes these areas:

The docs describe a few more working areas inside the same suite, such as Compliance › Access Reviews for user access review campaigns, Compliance › Crosswalk for approving mappings between frameworks, and Compliance › Privacy requests for data subject requests. They sit on the same control record, which is the point: an access review campaign produces evidence for the access controls, a privacy request leaves a record an auditor can read, and none of it lives in a separate spreadsheet.

Underneath, Lion (GA), Safeguard's compliance and narrative model, maps evidence to controls and drafts audit friendly summaries. Safeguard's models are security tuned; nothing here relies on them doing maths or science. You can also run the platform in Zero AI mode (GA), with no model in the loop, if your policy requires it.

How one control maps to several frameworks

This is the part that removes most duplicate work, so it is worth understanding exactly how Safeguard does it rather than assuming "map once, comply everywhere".

Four ways a framework is covered

Safeguard's framework docs describe four layers for every framework in the library:

1. Scan requirements. Each framework has requirements that Safeguard checks on every scan of a product, against what the scan found, including the product's SBOM. Most are decided by the scan as met or not met. Some are checked for a prerequisite, where a missing prerequisite fails the requirement but only evidence or an attestation can pass it. The rest need evidence a scan cannot see, such as a policy, an HR record or an access review; they pass when a person attests them with evidence. Each framework's page marks which kind every requirement is.
2. Controls. On a framework's Controls tab, scan requirements appear as controls. For many frameworks Safeguard's control catalogue adds more of the framework's own controls, which you evidence with automated tests, uploaded evidence, policies and attestations.
3. Automated tests. Connected systems run tests that map to controls of SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, and to CIS benchmarks for several clouds and Kubernetes. The docs note that each test carries a one sentence rationale an auditor can check.
4. Policy templates. Every framework has a standard set of policy templates adapted to it, and some frameworks have templates written specifically for them.

Tests, not connectors, carry the mapping

A detail from the docs that is easy to miss: connectors do not attach to a framework. A connector feeds tests, each test checks one thing in a connected system, and each test maps to the controls it provides evidence for. When a test passes, that result counts toward every control it maps to, in every framework it maps to. Connect a system once, and its tests count everywhere they apply.

So a single test that checks whether multi factor authentication is enforced in your identity provider can count toward a SOC 2 logical access criterion, an ISO/IEC 27001 Annex A access control and a NIST CSF 2.0 identity management outcome at the same time. The docs say a passing result is evidence toward a control, not proof on its own that the control is met. That matters: an access control is usually more than one setting.

The crosswalk, and why it needs a human

For evidence that does not come from a mapped test, Safeguard uses a crosswalk across SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and NIST SP 800-53. The rules in the docs are strict, and they are the right rules:

• Evidence counts toward a control in another framework only through an equivalent crosswalk row that has been reviewed, or that your workspace approved.
• It counts only while the evidence is accepted and in date.
• Every other related row is a suggestion for a person to review, never a pass.
• Credit never chains. Evidence produced through the crosswalk is not used as a source again.
• NIST SP 800-53 has no direct test mappings, so its automated evidence arrives through the crosswalk.

On Compliance › Crosswalk, a reviewer chooses Approve, Reject (with a reason) or Withdraw decision for each mapping. Approving an equivalent mapping makes accepted evidence for the source control count toward the target. Approving a partial mapping confirms the suggestion but makes nothing count. Decisions are never edited or deleted; each is a new record and the latest one applies. If a later crosswalk version changes the mapping text, the old approval no longer applies.

Why so careful? Because loose mappings are where multi framework programmes get into trouble with auditors. A SOC 2 criterion and an ISO control can look similar and still differ in scope. Requiring a person to approve equivalence, and refusing to chain credit, keeps the shortcut honest.

Frameworks without direct test mappings

Most frameworks in the library do not have tests mapped by Safeguard. For those, you link tests yourself: open the framework on Compliance › Frameworks, open the control, choose Link a test, search for the test and click Link. The result then counts toward that control the same way a catalogue mapping does. Edit mappings on the framework's tests lets you change several at once. Controls no test can check are evidenced with policies, uploaded evidence, records in Safeguard and attestations.

How readiness is shown per framework

Each framework gets a readiness score. Per the docs, it is the share of in-scope requirements that pass:

• 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 and 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.

Beside each score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation. That split is the most useful number on the page, because it tells you how much of the score is machine checked and how much rests on people.

The docs are direct about what the score is not: "not an audit opinion or a certification." Treat it as an internal readiness signal.

Step by step: from framework to a fixed control

This walkthrough follows the flows in Safeguard's docs. Where the docs do not show a specific screen, the step describes the outcome instead of inventing buttons.

1. Switch on 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 and select Save. It appears on Compliance › Frameworks, Controls and Overview. Out of the box, most frameworks are on, but the national data protection and cybersecurity laws are off: switch on the ones that apply to you. Your plan decides which frameworks your organization can choose, and your Safeguard administrator manages that list.

2. Set scope before you chase the score. For requirements that do not apply to you, scope them out with a written justification. They leave the score, and the justification is what an auditor will read. Do this early, or your readiness number will understate where you really are.

3. Connect a cloud account or identity provider. Open Compliance › Connectors. Search for the system or filter by category, by Automated evidence or Connection record only, and by Connected or Not connected. Click Connect on a card. Depending on the connector, the form offers:

   • OAuth, where you approve read access on the vendor's own consent screen and can revoke it there later;
   • API token, always available, where the form lists the read-only grant to create at the vendor; or
   • MCP server, which serves Search (Griffin AI) only. MCP connections cannot feed compliance tests, so use OAuth or an API token for evidence.

   Safeguard asks for the narrowest read-only grant the vendor offers and makes only read calls. Credentials are encrypted at rest and never shown again. A self-hosted system must be reachable at a public https address; Safeguard refuses private, loopback and cloud metadata addresses.

4. Confirm the connection is healthy. After you connect, the card shows Verified, Not working (with a reason such as a missing grant or wrong region) or Unverified (the provider did not answer the last check). Admins can Re-check one connection or Re-check all. Open a connected card for Test connection, Reconnect, Re-authorize, Rename, Disconnect or Remove. Disconnecting stops that connection's tests and keeps earlier results as history.

5. Choose what each connector collects. The What this connector collects panel lists every test and evidence check that reads from the connector, each with a switch. If two identity providers could answer the same test, switch it off on one and take it from the other. Some providers can be connected once per account, and every test then runs against each account and names the account in its result.

6. Check the framework's Connectors tab. Open the framework on Compliance › Frameworks, then its Connectors tab. It lists the connectors that answer that framework's tests, which ones you have connected, and whether each connection is healthy. This is where you find the gap between "we connected some things" and "this framework's tests can actually run".

7. Run the tests. Tests run on a schedule, roughly every six hours, and each test runs as often as it is due (daily by default). To run sooner, use Run now or Run all tests on Compliance › Tests. Two caveats from the docs: automated tests for a provider are switched on per workspace by the Safeguard team, so a new connection may show Verified before its tests run; and a newly added test starts in a preview period, typically 14 days, during which its results show but do not change any control's status, do not move your readiness score and open no tasks.

8. Handle legitimate exceptions properly. On a test's detail page, Exclude asks to exclude one resource, such as a break-glass account. Give a Reason, choose an Approver and set Expires on. Nothing is excluded until the approver approves it. Until expiry, the resource counts as not applicable with your reason shown as evidence. The Exclusions tab lists every exclusion and its state.

9. Attach evidence for what tests cannot see. Policies, training records, vendor reviews and board minutes do not come from an API. Upload them on Compliance › Evidence against the right control. Evidence starts as submitted, and a compliance reviewer chooses Accept or Reject, stamped with who, when and why. A result recorded by an automated test from its own run starts accepted. Changing accepted evidence creates a new version that goes back to submitted. Evidence with an end date becomes expiring inside its reminder window and expired from that date, which is how stale evidence stops quietly counting.

10. Get policies approved and acknowledged. Start a policy from a template on the framework's Policies tab (New policy, then Start from template), then Submit for review. A reviewer approves one version; editing an approved policy sends the new version to review while the approved one stays in force. A reviewer can Launch an acknowledgement campaign so staff acknowledge that specific version.

11. Assign and fix a failing control. Once a test is out of preview, a failing result counts against every control it maps to and can open a task. The docs pages we read do not show the exact assignment screen, so check in your workspace who receives these tasks and whether they route to your ticket tracker. Fix the underlying setting in the connected system, then use Run now on the test so the control reflects the fix without waiting for the next scheduled run.

12. Approve crosswalk mappings you rely on. On Compliance › Crosswalk, review the equivalent mappings between the frameworks you hold. Approve the ones that genuinely hold for your programme. Until you do, related rows stay suggestions.

13. Produce the report your auditor asked for. The compliance docs describe custom reports: navigate to Reports, click Create Report, select the compliance framework, configure scope and date range, then generate and export. The suite also keeps audit trails of who did what, which matters more to an auditor than any single export.

If you want a day in the life view of this loop, our post on a compliance lead's day to day in Safeguard walks through it, and the compliance reporting guide covers the reporting side in more depth.

How software supply chain findings become compliance evidence

Most compliance tools stop at cloud and identity settings. Safeguard's compliance suite sits on the same data as its software supply chain products, so what your scans find also feeds controls. That is useful because several standards now ask directly about the software you build and buy.

SBOMs and scan requirements

SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs for your projects. Each framework's scan requirements are checked on every scan of a product against what the scan found, including that SBOM. So a control about knowing your software components, or about managing technical vulnerabilities, is decided from current scan data rather than a document someone wrote last quarter.

This lines up with NIST SP 800-218, the Secure Software Development Framework. Task PS.3.2 asks producers to collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM, and the SSDF maps that task to the software supply chain provisions of Executive Order 14028. In the Portal (GA, here meaning the SBOM publish and share product rather than the free entry tier), SBOMs are checked against the NTIA minimum elements with a compliance score and gap analysis per SBOM.

If you want the SBOM side in detail, see the companion post on SBOM generation and analysis in Safeguard.

Policy outcomes

Policies, gates and guardrails (GA) evaluate your projects against rules you set, including rules written in plain English. A gate can block, warn, notify or require approval at a checkpoint such as CI or release. Those outcomes are records: a gate that blocked a release with a known exploited vulnerability, and the approval that later let a fixed build through, are exactly the kind of evidence a change management or vulnerability management control asks for. The plain English policies to release gates post covers how gates are built.

Attestations

Attestation and signing (GA) produces in-toto attestations, including SLSA provenance, CycloneDX and SPDX SBOM predicates and a vulnerability scan snapshot taken at build time. Safeguard's attestation docs show this CI step:

- name: Attest build
  uses: safeguard/attest@v2
  with:
    artifact: ./dist/app.tar.gz
    predicates:
      - slsa-provenance
      - sbom-cyclonedx
      - vuln-scan

Per the same docs, attestations are signed with Safeguard's own key held in a cloud key management service and verified with cosign against Safeguard's published public key. The docs also say there is no CLI command for signing container images and packages yet. A signed statement that a specific artifact was built from a specific commit, with a specific SBOM and vulnerability snapshot, is stronger evidence for a secure development control than a screenshot of a pipeline page. More on this in attestation and provenance in Safeguard.

Third parties and vendors

NIST CSF 2.0's GV.SC category and ISO/IEC 27001's supplier controls both expect you to know and assess suppliers. The Vendors area of the suite holds your vendor register, and TPRM (GA) handles the deeper work of requesting SBOMs from suppliers and scoring their risk. The supplier software risk post in this series covers that flow.

Working with an auditor: audit requests and questionnaires

Continuous evidence is only half of an audit. The other half is the conversation with the auditor, and Safeguard's docs are specific about who does what.

Audit requests

In an audit engagement, the auditor lists what they need. Your team answers each request and chooses Submit to auditor. The auditor then chooses Accept or Reject, with a reason for any rejection. Per the approvals docs, only auditors accept requests, draw samples, open findings and issue opinions.

The same docs draw a clear line in the other direction. The Auditor role on its own is not a compliance reviewer: an external auditor tests management's decisions and does not make them. So an auditor with read-only access cannot approve your policy or accept your evidence, and your team cannot accept its own submissions on the auditor's behalf. The compliance overview lists read-only assessor access among its audit support features.

That separation is what makes the record trustworthy. When the auditor samples a control, they see the evidence, who accepted it and when, the test history behind it and any exclusion with its approver and expiry.

Who can approve, and what assistants cannot do

A compliance reviewer makes decisions in the programme: an administrator, a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone granted the matching compliance permissions. If Safeguard cannot tell who is deciding, it refuses the decision rather than assume.

This matters if you drive Safeguard from an AI assistant. The MCP server (GA) lets assistants such as Claude read your programme and prepare changes within the access your workspace and role allow. The approvals docs set two hard rules: an MCP client runs a write only after you confirm it in that client, and even a confirmed write cannot approve, accept, launch or acknowledge anything. Those decisions are made by a person in the app. In-app agentic search (early access) follows the same rule, showing a Confirm or Cancel card for every write.

Security questionnaires

The Questionnaires area holds the security questionnaires your customers send you. Drafting answers automatically from your evidence is part of the Trust Center, which is early access. Treat any drafted answer as a first draft: a person who knows the system should check each one before it goes out, because a questionnaire answer is a statement your sales team will be held to. Our post on preparing for a security questionnaire with Safeguard goes through that workflow.

The Trust Center, briefly

The Trust Center (early access, switched on per workspace) publishes a public page at a slug under trust.safeguard.sh. Published controls are read live from continuous monitoring, so a control that starts failing shows as failing without a republish. Framework statuses are Compliant, In progress, Not assessed or Signed, and the docs say a framework that needs an independent auditor or certification body cannot be declared compliant on a self-assessment. Only a compliance reviewer or administrator can publish the auditor's opinion. The step by step is in setting up a Safeguard Trust Center, and our general guide on how to build a trust center covers what to publish.

Which connectors are live today, and how to request one

This is the area where you should read the fine print before you plan.

What Safeguard says. The offering guidance is that roughly 50 evidence connectors are live today, with the rest available on request. Safeguard's catalogue lists far more integrations than that, across categories such as identity and single sign-on, cloud infrastructure, version control, ticketing, device management, endpoint, HR and observability.

What the docs show per connector. The connectors page labels what each connection actually produces: automated compliance tests, automated evidence collection, people sync, attested evidence, search only, or a connection record. A connection record stores the connection as evidence for its category, but automated collection is not available for that provider yet. The docs also say automated tests are switched on per workspace by the Safeguard team.

How to plan around that.

• For each framework you hold, open its Connectors tab and list the connectors it needs that you run.
• For each one, check the card's evidence type. "Automated compliance tests" or "Automated evidence collection" is what removes screenshot work. "Connection record" means you still upload evidence by hand.
• Ask Safeguard to confirm that tests are switched on for your workspace before you count them in an audit plan.

How to request a connector. Open Compliance › Connectors and choose Request integration (or the Request an integration link under the page title). Fill in the integration name (required), its website, the closest category and what you would use it for, for example "MFA status of every user". Choose Submit request. The request is saved to your workspace with the status requested, under your name and time, and the Safeguard team reviews it and follows up. Until it exists, the docs suggest two workarounds: connect the vendor's MCP server with Add custom MCP if one exists (useful for Search, not for tests), and upload evidence for its controls by hand on Compliance › Evidence.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

Being clear about this is part of using the product well.

• It does not perform your audit or issue a report. Safeguard holds the evidence, tests and history an auditor works from. A licensed CPA firm issues a SOC 2 report, an accredited certification body issues an ISO/IEC 27001 certificate, and a qualified assessor handles PCI DSS assessments. None of that moves into the software.
• It does not certify you, and the readiness score is not an opinion. The docs say so in plain words. A score of 100 means every in-scope requirement Safeguard tracks passes; it does not mean an auditor will agree, and it does not cover controls you scoped out or never mapped.
• It does not give you automated evidence for every system you run. Roughly 50 evidence connectors are live today. Many listed connectors store only a connection record, and automated tests are switched on per workspace by the Safeguard team. Expect to upload some evidence by hand.
• It does not map tests to every framework. Direct test mappings exist for SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and several CIS benchmarks. For other frameworks you link tests to controls yourself, and the crosswalk only carries evidence through equivalent mappings a person has approved.
• It does not make decisions for you. Evidence acceptance, policy approval, risk acceptance, test exclusions and crosswalk approval need a human reviewer. Neither the AI assistant nor an MCP client can make them, and neither can the auditor.
• It does not fix the systems a failing test reads. A test that finds logging switched off in a cloud account tells you; someone with access to that account still turns it on. Autonomous remediation (GA, ships switched off with every category set to Manual) opens pull requests for code and dependencies, not changes in your cloud console or identity provider.
• It does not write your non technical controls. Background checks, security awareness training, vendor contracts and board oversight are evidenced in Safeguard but carried out by people and processes outside it.
• The Trust Center is early access. It shows what you configure plus live control status. It is not an independent attestation, and you should review every published item before turning it on.

Common mistakes

Counting a connector before its tests run. A card can show Verified while tests for that provider are not yet switched on for your workspace, or while new tests sit in their preview period. Check the Tests page for real results before you tell an auditor a control is automated.

Treating the readiness score as the goal. Scoping out requirements to raise the number is easy and visible. Each scope decision carries a written justification an auditor will read. Scope honestly and let the score be lower.

Approving every crosswalk suggestion. Partial mappings exist for a reason. Approve only equivalent mappings you would defend in front of the auditor for both frameworks.

Letting evidence expire quietly. Set end dates on evidence that has a natural life, such as an annual penetration test or a policy acknowledgement, so it moves to expiring and then expired instead of counting forever.

Excluding resources without an expiry. The exclusion flow requires an approver and an expiry date for a reason. Break-glass accounts and legacy systems should be revisited, not forgotten.

Using an MCP connection for evidence. MCP server connections serve Search. They cannot feed compliance tests. Use OAuth or an API token where the connect form offers them.

Granting broad access to make a connector work. The setup guides ask for the narrowest read-only grant. If a vendor has no read-only option, the guide says so; decide deliberately rather than handing over an admin key by default.

Keeping supply chain evidence in a separate world. If your SBOMs, gate decisions and attestations live only in the engineering pipeline, your secure development controls get evidenced by hand at audit time. Let scans and policy outcomes feed the controls they already answer.

FAQ

Is Safeguard's compliance suite generally available?

Yes. The compliance and GRC suite is GA, as are evidence connectors (roughly 50 live, more on request) and Lion evidence mapping. The Trust Center within the suite is early access and switched on per workspace.

Does Safeguard replace my SOC 2 or ISO 27001 auditor?

No. Safeguard keeps controls, evidence, tests and history current and lets an auditor work through audit requests. The auditor or certification body still tests your controls and issues the report or certificate.

How often do Safeguard compliance tests run?

Per the docs, tests run on a schedule of roughly every six hours, and each test runs as often as it is due, daily by default. You can trigger them sooner with Run now or Run all tests on Compliance › Tests.

Can one piece of evidence count for SOC 2 and ISO 27001 at the same time?

Yes, in two ways. A passing automated test counts toward every control it maps to across the mapped frameworks. Other accepted evidence carries across through crosswalk rows marked equivalent that were reviewed or approved by your workspace, and only while the evidence is accepted and in date.

What does the readiness score in Safeguard measure?

The share of a framework's in-scope requirements that pass, either by a scan finding them met or by a person attesting them with evidence. Scoped out requirements leave the score. It is Safeguard's assessment of what it can see, not an audit opinion.

Which frameworks have automated test mappings?

SOC 2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, plus CIS benchmarks for several clouds and Kubernetes. NIST SP 800-53 receives evidence through the crosswalk. For other frameworks you link tests to controls yourself with Link a test.

What happens if a connector I need is not available?

Use Request integration on Compliance › Connectors. Until it exists, upload evidence for its controls on Compliance › Evidence, and optionally connect the vendor's MCP server for Search.

Can an AI assistant approve evidence or policies in Safeguard?

No. Through the MCP server or in-app search, an assistant can read your programme and prepare changes you confirm, but it cannot approve, accept, launch or acknowledge anything. A person in the app makes those decisions.

Do SBOMs and scan results count as compliance evidence?

Yes. Each framework's scan requirements are checked against what a scan found, including the SBOM, and policy outcomes and signed attestations are records your secure development and vulnerability controls can rely on.

Can auditors log in to Safeguard?

The compliance docs list read-only assessor access, and audit engagements let auditors accept or reject what you submit against their requests. The Auditor role alone cannot make decisions in your programme.

From a failing control to a fix

A large share of the controls that fail in a continuous programme are vulnerability management controls, such as ISO/IEC 27001 A.8.8 or NIST CSF 2.0 ID.RA-01, and they only turn green when the vulnerable component is actually replaced. The evidence follows the fix, so here is how Safeguard helps you make the fix.

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 covers eight categories, including dependencies, licenses, security posture and findings. 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. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

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

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature 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. This fork and patch flow is in early access today, so 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

Neither demo below shows the compliance screens. They show two ways people drive Safeguard day to day, and both apply to the evidence loop described above.

The first demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. For a compliance lead, the same connection lets an assistant read your programme, for example listing failing controls or summarising which evidence expires this month. As the approvals docs require, it can prepare changes you confirm, but it cannot accept evidence or approve a policy.

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

The second demo is a real session in the desktop app (early access, beta). 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 vulnerability management control is failing because of a dependency, this is the same approve each step flow that gets the fix in, after which a rescan updates the control.

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

To try it on your own estate, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For a broader map of what is GA and what is early access, start with what Safeguard does today.

Quick check

Sources

• Safeguard docs: Compliance
• Safeguard docs: Compliance frameworks
• Safeguard docs: All frameworks
• Safeguard docs: Frameworks and connectors
• Safeguard docs: SOC 2 and connectors
• Safeguard docs: ISO/IEC 27001 and connectors
• Safeguard docs: NIST CSF 2.0 and connectors
• Safeguard docs: HIPAA Security Rule and connectors
• Safeguard docs: PCI DSS and connectors
• Safeguard docs: Connectors
• Safeguard docs: Compliance connectors
• Safeguard docs: Requests and approvals
• Safeguard docs: Approvals
• Safeguard docs: Integration requests
• Safeguard docs: Trust Center setup
• Safeguard docs: Portal compliance
• Safeguard docs: Attestation and signing
• Safeguard: Products
• Safeguard: Capabilities
• AICPA: 2017 Trust Services Criteria with revised points of focus (2022)
• NIST: The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29
• NIST: Cybersecurity Framework
• NIST SP 800-53 Rev. 5, Security and Privacy Controls
• NIST SP 800-53 Rev. 5 control catalog (CPRT), CA-7
• NIST SP 800-137, Information Security Continuous Monitoring
• NIST SP 800-218, Secure Software Development Framework v1.1
• eCFR: 45 CFR 164.308, Administrative safeguards
• PCI Security Standards Council: Document library

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