Working Toward SOC 2 With Safeguard: Controls, Tests and Evidence

Safeguard's Compliance and GRC suite (GA) helps you prepare for a first SOC 2 Type 1 or Type 2 examination by laying out every Trust Services Criterion, marking which ones a scan decides and which need a person's evidence, running automated tests against the systems you connect, and keeping policies and evidence with a reviewer's decision attached. It gets you ready for the audit. It does not perform the audit: a licensed CPA firm examines your controls and issues the SOC 2 report.

This post is for the founder, head of engineering or first compliance hire whose big customer will not sign without a SOC 2 report. It covers what SOC 2 asks for, how Safeguard splits the criteria, where supply chain evidence fits, a step by step setup, a 90 day plan, and what stays with you and your auditor.

Key takeaways

• SOC 2 is an attestation report, not a certificate. A CPA firm examines your controls against the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022) and issues an opinion. Type 1 looks at control design at a point in time; Type 2 looks at whether controls operated across an observation window.
• Compliance and GRC suite: GA. SOC 2 Type 1 and SOC 2 Type 2 each have a framework page in Safeguard that lists every criterion and marks it as decided by a scan, a scan then evidence, or evidence only.
• Automated tests and evidence connectors: GA, with roughly 50 connectors live today and the rest available on request. Tests from your identity provider, cloud accounts and code host map straight to SOC 2 controls.
• SBOM generation and analysis, SCA and vulnerability management, policies and gates: all GA. These feed the supply chain side of CC6.1, CC6.8, CC7.1, CC7.2 and CC9.2.
• Lion evidence mapping and narrative (named Lino in parts of the docs): GA. It drafts and maps; people decide.
• Third party risk management (TPRM): GA. Useful for the vendor half of CC9.2.
• Trust Center: early access. Optional, for sharing your report under NDA once you have one.
• Autonomous remediation: GA, ships switched off. Relevant when a failing vulnerability control needs code changes.
• People still own a lot. Management's assertion, the system description, HR and board evidence, access review sign offs and the auditor's sampling are outside what any platform produces.

What SOC 2 is, who issues it, and how Type 1 and Type 2 differ

SOC 2 is one of the AICPA's System and Organization Controls services. The AICPA's guide describes it as an "assertion-based examination" of a service organization's description of its system and the controls in it. In plain terms: you, as management, describe your system and assert that your controls meet the criteria; an independent CPA firm examines that assertion and gives an opinion. The AICPA's SOC pages say these are services that "CPAs may provide", which is why no software vendor, consultancy without a CPA licence, or compliance platform can issue one.

Two documents set the bar:

• The 2017 Trust Services Criteria, with revised points of focus (2022). The AICPA's Assurance Services Executive Committee publishes these as "control criteria" for evaluating controls over security, availability, processing integrity, confidentiality and privacy.
• The 2018 SOC 2 Description Criteria, with revised implementation guidance (2022). These are the benchmarks for preparing and evaluating the description of your system. Practitioners call them DC 200.

The examination itself is performed under the AICPA attestation standards. The AICPA's illustrative SOC 2 Type 2 report notes that it meets the reporting requirements of SSAE 21, effective for service auditor reports dated on or after 15 June 2022.

Type 1 versus Type 2

Safeguard's own framework pages summarise the difference well. The SOC2 Type 1 page calls it a "point-in-time assessment of control design". The SOC2 Type 2 page describes criteria "assessed for operating effectiveness across the observation window".

A Type 2 window is unforgiving in one specific way: you cannot create past evidence later. If your quarterly access review did not happen in month two, no amount of work in month five fixes that sample. That is the main reason a spreadsheet programme fails during a Type 2, and the main reason to have evidence collected and timestamped as you go.

SOC 2 versus SOC 3

The AICPA describes SOC 3 reports as covering the same areas without "the same level of detail", so they can be freely distributed. A SOC 2 report holds the detail of your controls and the auditor's tests, so companies usually share it under NDA.

Which Trust Services Criteria are mandatory, and which are optional

The criteria are grouped into five categories. Security is the one every SOC 2 examination covers, and it is expressed through the common criteria, CC1 to CC9. Availability, confidentiality, processing integrity and privacy add their own criteria (A1, C1, PI1 and P1 to P8) when the commitments you make to customers call for them. Safeguard's SOC2 Type 1 page states the same split: the full CC1 to CC9 common criteria, "with Availability, Confidentiality, Processing Integrity, and Privacy visible as optional scope".

The common criteria break down like this:

The vocabulary in CC1 to CC5 (control environment, risk assessment, control activities, information and communication, monitoring) comes from COSO's Internal Control Integrated Framework, which COSO first issued in 1992 and refreshed in 2013. That is why the first five series read more like corporate governance than security engineering, and why engineers are often surprised that half of SOC 2 is about people and paperwork.

How to pick your categories

Choose categories from what you have promised customers. An uptime commitment points to availability; confidentiality terms point to confidentiality. Privacy is a large set of criteria on notices, consent, retention and data subject rights, so add it only with a reason your auditor agrees with.

In Safeguard, a criterion you leave out is scoped out with a written justification, and it then leaves the readiness score. Note one wrinkle in Safeguard's docs: the SOC2 Type 2 page describes availability, confidentiality and processing integrity as being in required scope alongside security by default. Treat that as the starting configuration of the Type 2 page, not as an AICPA rule. Your scope is the one you agree with your auditor, and you can scope criteria out in Safeguard with the justification your auditor will read.

How the SOC 2 pages in Safeguard split the criteria

Safeguard's framework library treats SOC2 Type 1 and SOC2 Type 2 as two frameworks over the same criteria. Safeguard's "SOC2 and connectors" page says so directly: "The same criteria serve SOC2 Type 1 and SOC2 Type 2." Both are on in your workspace unless you switch them off, and your Safeguard plan decides which frameworks your organization can choose from.

Each framework page lists every criterion with what Safeguard checks and a "Decided by" label. There are three labels, and the docs define them precisely:

• Scan. The scan decides whether the requirement is met.
• Scan, then evidence. The scan checks a prerequisite and fails the requirement when it is missing. Only evidence or an attestation can pass it.
• Evidence. A scan cannot see what the requirement asks for. It passes when a person attests it with evidence.

Here is what that looks like for the criteria a scan touches, taken from the SOC2 framework pages on docs.safeguard.sh (wording shortened):

Every other criterion, from CC1.1 to the privacy series, is labelled Evidence. That is honest: a product scan sees your software, not your board minutes, hiring process or restore test.

Two more layers sit on top of the scan requirements:

1. Controls and automated tests. On the framework's Controls tab, the scan requirements appear as controls, and Safeguard's control catalogue adds more SOC 2 controls that you evidence with automated tests, uploaded evidence, policies and attestations. Automated tests from connected systems map directly to SOC 2 controls, so an Evidence criterion such as CC6.2 can still be backed by data from your identity provider rather than a screenshot.
2. Policy templates. The SOC 2 pages carry templates written for SOC 2 plus Safeguard's standard set adapted to it. For Type 1 the SOC 2 specific templates are an Information Security Policy, a Logical Access Management Policy, a Change Management Policy and a Vendor and Third Party Risk Management Policy. For Type 2 they are a Continuous Monitoring and Control Testing Policy, an Availability and Business Continuity Policy, an Incident Detection and Response Policy and a Vendor Risk Periodic Assessment Policy.

For how the readiness score is computed across all of these, the short version from the docs: it is the share of in-scope requirements that pass; a requirement waiting for evidence counts as not yet passing; a scoped out requirement leaves the score; and the score "is Safeguard's assessment of what it can see. It is not an audit opinion or a certification." Our earlier post on continuous compliance in Safeguard covers the general model across frameworks; this post stays on SOC 2.

Which automated tests map to SOC 2, and how to request a missing connector

An automated test checks a setting in a connected system against a control and records the result as evidence. Safeguard's "Frameworks and connectors" page lists SOC 2 among the frameworks the test catalogue maps to directly, with a one sentence rationale per test "an auditor can check". The other directly mapped frameworks are ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and the CIS benchmarks.

The SOC2 connectors page groups the systems by what kind of evidence they produce. The categories that matter most for a first SOC 2 are:

The connectors page lists exact control mappings per connector and links to setup steps. Read that page for your actual stack rather than relying on this summary table.

What availability looks like today

Safeguard's catalogue lists many more connectors than are live. The offering position is plain: roughly 50 connectors are live today, and the rest are available on request. The docs page for SOC 2 shows the catalogue's mappings, not live availability, so check the Connectors page in your own workspace before planning around a specific system.

Three behaviours from the docs are worth knowing before you connect anything:

• Tests are switched on per workspace by the Safeguard team. A new connection can show Verified before any of its tests run. If you see a healthy connection and no test results, ask support rather than assuming the integration is broken.
• New tests start in a preview period, typically 14 days. During preview their results show on the Tests page, but they do not change a control's status or your readiness score, and they open no tasks. Plan for this in the first month.
• Tests run on a schedule. The docs say the scheduler runs about every six hours and each test runs as often as it is due, daily by default. Run now and Run all tests on Compliance › Tests force an immediate run.

Some systems publish no API for what a test checks. The SOC 2 connectors page lists these under "Evidence by attestation": you connect them to record the connection, then attest the result, and an accepted attestation counts toward the control.

Requesting a connector that is not live

On Compliance › Connectors, Request integration sends Safeguard a request for a connector it does not list yet. Make the request early; until a connector is live, you upload exports from that system by hand, on time, for the whole window.

Where software supply chain results become SOC 2 evidence

This is the part of SOC 2 where Safeguard's core product does the most direct work, because it is the part a scan can actually see.

CC7.1: recurring vulnerability scanning

CC7.1 asks you to detect configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities. On the SOC 2 page it is the criterion a scan decides outright. Safeguard's SCA and vulnerability management (GA) builds a full transitive inventory and matches it against vulnerability sources including NVD, GHSA, OSV and CISA KEV. Every product scan becomes a dated record that scanning happened and what it found.

For a Type 2, the auditor also wants to see that what scanning found was handled. That is where remediation records come in: findings with a status, a priority and an exposure window measured against your SLA. Our sibling post on prioritising with reachability, EPSS and KEV covers how that ranking works.

NIST's Secure Software Development Framework (SP 800-218) frames the same expectation from the developer's side. Its practice RV.1, "Identify and Confirm Vulnerabilities on an Ongoing Basis", and task PW.4.4, verifying that acquired open source and third party components meet your requirements "throughout their life cycles", are good language to borrow in your vulnerability management policy, because they describe a continuous duty rather than an annual scan.

CC6.1, CC6.8 and CC7.2: inventory and provenance

Three criteria use your software inventory as a prerequisite. CC6.1 treats a complete, current inventory of system components as the foundation for logical access security. CC7.2 needs every component identified by version before change and anomaly detection make sense. CC6.8 uses integrity hashes and known licenses as evidence that you can detect unauthorized third party software.

Safeguard's SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs on each scan, which is the inventory these criteria look for. A component with no version or supplier can fail the prerequisite. That is also why a readiness score can drop after a scan even though nobody changed a control: a new SBOM brought in a component that is missing data. NIST SP 800-218 task PS.3.2 makes the same point about provenance, asking producers to collect and maintain provenance data "for all components of each software release", for example in an SBOM.

Remember what "Scan, then evidence" means for these three. A good SBOM stops the requirement failing on the prerequisite. It does not pass CC6.1 on its own: you still need the SSO, MFA and least privilege evidence, much of which the identity provider tests supply.

CC8.1: change management

On the SOC 2 page, CC8.1 is labelled Evidence. Code host tests cover branch protection and review settings, and two more Safeguard features produce useful supporting records:

• Policies and gates (GA). Gates enforce policies at checkpoints with block, warn, notify or require approval actions, and a CI gate action is available. A record that a release was blocked until a critical finding was fixed is good change management evidence.
• Plain English policy creation (GA). Useful for writing the rule your change management policy describes in the same words the gate enforces. See plain English security policies to release gates.

Gate outcomes support CC8.1; they do not replace the evidence an auditor samples there, such as approved pull requests and test runs for the changes they pick. Our post on SOC 2 CC8 change management control ideas goes deeper on that criterion.

CC9.2: vendors and suppliers

CC9.2 is split in two. The scan half is a complete inventory of third party software suppliers, which the SBOM gives you for the open source and commercial components you ship. The evidence half is vendor assessments and agreements. The suite's Vendors area and Safeguard's TPRM (GA) cover the vendor register and assessments; the contracts themselves come from you. Supplier software risk with Safeguard TPRM shows that workflow.

For a longer mapping of supply chain evidence to SOC 2 controls, see SOC 2 control mapping with supply chain evidence.

Step by step: switch on SOC 2, connect, test, write policies, attest, review

These steps follow the flows in Safeguard's docs. Screen names are as the docs give them. Where the docs do not show a screen, the step describes the outcome instead.

1. Confirm SOC 2 is switched on. Open Compliance › Manage, then the Frameworks tab. Search for SOC2. Both SOC2 Type 1 and SOC2 Type 2 are on unless someone switched them off. If you are going for Type 1 first, you can keep both on; they share the same criteria. Select Save after any change. The framework then appears on Compliance › Frameworks, Controls and Overview. If you cannot find it, your plan or your Safeguard administrator controls which frameworks your organization can choose.

2. Set scope. Decide with your auditor which categories beyond security are in scope. For each criterion you leave out, scope it out with a written justification. The justification is part of your record, and the scoped out criterion leaves the readiness score.

3. Make sure your products are being scanned. The scan requirements are checked "on each scan of a product". Connect your repositories or upload artifacts so the products that make up your SOC 2 system boundary are scanned on a schedule or on push. If you are still choosing how Safeguard reaches your code, read repo connection, CLI or local runner. Products group projects, so it helps to create one product that matches the system you will describe to your auditor.

4. Connect your systems. Open the framework on Compliance › Frameworks (SOC2 Type 1 or SOC2 Type 2), then its Connectors tab. It lists the connectors that answer the framework's tests, which ones you have connected, and whether each connection is healthy. Start with your identity provider, your main cloud account and your code host. On Compliance › Connectors, select Connect on a card, choose OAuth or API token (the connect form lists the read only grant to create at the vendor), and connect. Credentials are encrypted at rest and never shown again. Use What this connector collects to switch off any test you will take from a different connector instead.

5. Run the tests. On Compliance › Tests, use Run now or Run all tests rather than waiting for the schedule. Expect new tests to sit in their preview period at first. Read failing results now, while you have time to fix the underlying settings.

6. Handle legitimate exceptions properly. A break glass account will fail an MFA test by design. On the test's detail page, Exclude asks to exclude that one resource: give a Reason, choose an Approver and set Expires on. Nothing is excluded until the approver approves it. Expect your auditor to ask about every exclusion, so keep reasons specific.

7. Start your policies from templates. Open SOC2 on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template. Edit the template until it describes what you actually do. On Compliance › Policies, Submit for review sends it to a compliance reviewer, and approval covers that version. The effective date defaults to the approval day and the next review to a year later.

8. Attest an Evidence criterion. Pick a criterion no scan or test can see, for example CC1.4, commitment to competence. Upload the evidence (your hiring procedure and a record of background checks for the period, say) on Compliance › Evidence against the control. It starts as submitted; a compliance reviewer chooses Accept or Reject, and the decision is stamped with who, when and why. Give evidence an end date where it naturally expires, so it shows as expiring inside its reminder window instead of silently going stale.

9. Record risks. CC3.2 asks for a risk register with owners. On Compliance › Risks, record each risk with an owner. Accepting a high or critical residual risk needs an approver with an admin role and a review date within a year; low and medium risks can be accepted by their owner.

10. Review readiness. Open the SOC 2 framework on Compliance › Frameworks and read the readiness score together with the two numbers beside it: how many requirements a scan evaluated and how many need evidence or an attestation. The second number is your remaining work list. A score near 100 means the criteria Safeguard can see are passing; it does not mean an auditor will agree, and the docs are explicit that it is not an audit opinion.

Who can make the decisions in steps 6 to 9

Safeguard's approvals docs define a compliance reviewer: an administrator, a holder of the GRC role or a compliance admin, manager or reviewer role, or anyone with the matching compliance permission. Three rules sit on top. The Auditor role alone is not a reviewer, because "an external auditor tests management's decisions and does not make them". Safeguard's AI assistant and MCP clients can draft and submit but never accept, approve, launch or acknowledge. And if Safeguard cannot tell who is deciding, it refuses the decision. For SOC 2 this matters because CC1.3 and CC5.3 are about who is responsible for what, and an auditor will look at who approved your evidence.

Requirement, what Safeguard does, what you still own

What an auditor still needs that Safeguard cannot produce

Even with every Scan criterion passing and every test green, these come from you or your auditor:

• Management's assertion. A written statement by your management that the description is fairly presented and the controls are suitably designed (and, for Type 2, operated effectively). Management signs it, not a platform.
• The system description. Written to the AICPA's description criteria: services, system boundaries, infrastructure, software, people, data, processes, commitments and complementary user entity controls. Safeguard's Lion can help draft narrative, but the description is yours and must match reality.
• Sampling and testing. The auditor chooses samples (new hires, terminations, changes, incidents) and tests them. A platform record makes that faster; it does not stand in for it.
• The opinion. Only the CPA firm issues it. Whether a test result counts as sufficient evidence is the auditor's judgement, not the platform's.
• Things outside the boundary of what is connected. If a system is not connected or scanned, Safeguard has nothing to say about it, and its absence will not show in the score.

The first 90 days, then the observation window

The weekly check during the window is the single habit that matters most. A failing test you notice in week two is a configuration fix. The same failure noticed at fieldwork is an exception in your report.

What Safeguard does not do

• It does not perform or sell your SOC 2 audit in this context. A licensed CPA firm examines your controls and issues the report. Safeguard prepares and organises your evidence.
• It does not write your system description or management's assertion. Lion can help with narrative, but both documents are management's responsibility and must describe what you actually run.
• It cannot evidence most of CC1 to CC5 on its own. The SOC 2 pages mark those criteria Evidence because a scan cannot see them. People supply and attest that evidence.
• It has roughly 50 evidence connectors live today. The catalogue lists far more; the rest are available on request. Systems without a live connector need uploaded evidence or an attestation.
• Automated tests are not instant. The Safeguard team switches tests on per workspace, and new tests spend a preview period without affecting control status.
• It does not change your systems for you. A failing MFA test is fixed in your identity provider. Exclusions record an approved exception; they do not fix anything.
• It does not see what is not connected or scanned. The readiness score covers only what Safeguard can see, and it is not an audit opinion or a certification.
• Nothing in this post is a statement about Safeguard's own SOC 2 status. It is about helping your company work toward its report.

Common mistakes

Treating the readiness score as the answer. A high score means the in scope criteria Safeguard can see are passing. It says nothing about systems you have not connected or criteria you scoped out. Read the "need evidence" number next to it and the list of scoped out criteria before you quote the score to anyone.

Starting Type 2 before the evidence routine exists. If the access review, vendor review and policy review cadence is not running on day one of the window, the first quarter of samples is already lost. Run a Type 1 or a few dry run months first.

Scoping in every category. Each extra category adds criteria to evidence for the whole window. Scope to what you have promised customers.

Using an exclusion as a fix. Exclusions are for genuine exceptions such as break glass accounts, approved by someone else and set to expire. An auditor will read each one.

Ignoring SBOM quality. Components without versions or suppliers fail the prerequisite for CC6.1, CC7.2 and CC9.2. Fixing the build metadata fixes the criteria.

Letting the same person submit and approve. Segregation of duties is part of what CC1.3 and CC5.3 look at. Assign reviewers who did not prepare the evidence.

Waiting for a connector instead of requesting it. If a system you need is not live, use Request integration in week one and upload exports in the meantime.

Uploading undated evidence. Evidence without the period it covers tells an auditor nothing about operating effectiveness. Date every item and set an end date where one applies.

FAQ

Can Safeguard make my company SOC 2 compliant?

No platform can. Safeguard's Compliance and GRC suite (GA) helps you organise controls, run tests and collect evidence. A CPA firm examines your controls and issues the SOC 2 report. Safeguard's docs say plainly that choosing a framework does not certify compliance and that the readiness score is not an audit opinion.

Should I start with SOC 2 Type 1 or Type 2?

Many first time companies do a Type 1 to show customers that controls are designed and in place, then run a Type 2 window. If a buyer will accept only Type 2, start the window as soon as your recurring controls are actually running. Safeguard has a page for each, and they share the same criteria.

Which SOC 2 criteria can Safeguard decide automatically?

From scans, CC7.1 (recurring vulnerability scanning) is decided by a scan. CC6.1, CC6.8, CC7.2, CC9.2 and PI1.5 are checked for a prerequisite and then need evidence. Automated tests from connected systems add evidence for many more controls, including access, encryption and change management. Everything else needs a person's evidence.

Does an SBOM count as SOC 2 evidence?

Yes, for the parts of SOC 2 that rely on knowing what software you run. Safeguard's SOC 2 pages use the SBOM as the prerequisite for CC6.1 and CC7.2, use provenance data such as integrity hashes and licenses for CC6.8, and treat the supplier inventory as the foundation for CC9.2. It is necessary evidence, not sufficient on its own.

How long does it take to get ready for a SOC 2 audit?

It depends mostly on how much of CC1 to CC5 already exists as written, approved and followed practice. A plan of about 90 days to readiness is common for a small, cloud native company, followed by the Type 2 observation window your auditor agrees. Automated tests save collection time, but writing policies, assigning owners and running recurring reviews take the calendar time.

What happens if a connector I need is not available?

Use Request integration on Compliance › Connectors. In the meantime, upload evidence exports from that system against the relevant control, or attest the result. Roughly 50 connectors are live today, with the rest available on request.

Can my auditor log in to Safeguard?

Safeguard has an Auditor role. The approvals docs say the Auditor role alone is not a compliance reviewer, because an auditor tests management's decisions rather than making them. Agree with your auditor how they want to receive evidence; some prefer exports.

Can Claude or ChatGPT manage my SOC 2 programme through Safeguard?

They can read and draft within the access your workspace allows. Safeguard's docs say an assistant or MCP client can draft and submit but never accept, approve, launch or acknowledge anything, whoever is signed in. Add Safeguard from the Claude connector directory or the ChatGPT apps route; the MCP server is GA, and which tools appear depends on your plan and admin settings.

Can I share my SOC 2 report through Safeguard?

The Trust Center (early access) can hold restricted documents behind access requests that a reviewer approves, and the approvals docs say only a compliance reviewer or administrator can publish or take down the auditor's opinion there. See set up a Safeguard Trust Center.

Fix the vulnerability findings that keep CC7 red

CC7.1 passes when scanning happens, but a Type 2 auditor will also sample how quickly you fixed what the scans found. The section below explains how Safeguard helps close that gap between a finding and a fix in production, which is what keeps your vulnerability management evidence clean through the window.

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

None of the demos below shows the compliance screens. They show how people drive Safeguard day to day, and each one maps onto a part of the SOC 2 work 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 first compliance hire, the same connection lets an assistant read your data and draft, for example a summary of open critical findings to attach as CC7 context. Add Safeguard from Claude's connector directory rather than setting up a custom connection, and remember the assistant can prepare work but 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 Safeguard CLI session (GA). It installs the CLI, opens the interactive terminal, and asks it to fix the lodash CVE in a repository; the CLI reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That approve each step pattern is how an engineer clears a vulnerability finding that is holding back CC7 evidence, with a record of what changed.

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

The third 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. For a small team preparing for SOC 2, it is a way to get the same fix done with a human approving every step, which is the kind of change record CC8.1 looks for.

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

To start, download Safeguard at safeguard.sh/download and read the setup guides at docs.safeguard.sh/docs. For background on the criteria themselves, read SOC 2 Trust Services Criteria explained, and for the questionnaires that arrive alongside SOC 2 requests, prepare for a security questionnaire with Safeguard. For a map of every capability and its label, see what Safeguard does today.

Quick check

Sources

• AICPA: System and Organization Controls (SOC) suite of services
• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• AICPA: 2018 SOC 2 Description Criteria (with revised implementation guidance, 2022)
• AICPA: SOC 2 Reporting on an Examination of Controls at a Service Organization (guide)
• AICPA: Illustrative service auditor's SOC 2 Type 2 report
• AICPA: SOC 3, SOC for Service Organizations, general use report
• COSO: Internal Control Integrated Framework
• NIST SP 800-218, Secure Software Development Framework 1.1
• NIST SP 800-218 full text (PDF)
• Safeguard docs: SOC2 Type 1
• Safeguard docs: SOC2 Type 2
• Safeguard docs: SOC2 and connectors
• Safeguard docs: Frameworks and connectors
• Safeguard docs: Compliance frameworks
• Safeguard docs: Compliance connectors
• Safeguard docs: Approvals
• Safeguard docs: Requests and approvals

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