Can a Solo Founder Get SOC 2 Type 2, and Is It Worth It?

Yes, a solo founder can get a SOC 2 Type 2 report. Nothing in the AICPA framework requires a minimum headcount, but you have to show an independent CPA how changes get reviewed, how access stays limited and how risks get caught when there is no second employee. Whether it is worth it depends on whether a real deal is waiting on the report.

For most one person companies the honest order is: build the controls and the evidence now, answer questionnaires with a clear security packet, and buy the audit when a signed or near signed customer asks for it. The rest of this post explains how auditors treat the one person problem, what a Type 2 costs in money and time, which controls are hardest to evidence alone, and what to set up this week so the eventual audit is short and cheap.

Key takeaways

• No small company exemption, and no small company ban. You meet the same criteria as a larger firm, using automated checks, branch protection and outside reviewers instead of a second engineer.
• Segregation of duties is the core problem. When one person writes, approves and deploys, the auditor wants an alternative control performed by a machine or an outside party, with evidence it ran all period.
• Type 1 first is usually cheaper. Type 1 tests design on one date. Type 2 tests operation over a window small companies commonly set at three to twelve months.
• Budget real money. One firm that sells these services quotes $12,000 to $45,000 in startup scope Type 2 audit fees and $30,000 to $90,000 all in for year one.
• Vulnerability evidence is the easiest win. Scans on every pull request, a written patch timeline, dated fix pull requests and an SBOM per release can all be automated.
• A security packet often closes the first deals. Many buyers accept questionnaire answers, policies, a penetration test and a dated commitment to a report.
• Pick the auditor carefully. The AICPA warned publicly in 2026 about "fast and easy" SOC engagements.

Why so many solo founders are asking this right now

The question shows up constantly in founder forums. One widely discussed Ask HN thread came from a solo founder of a SaaS product who asked whether it was possible to become SOC 2 Type 2 compliant without spending more than $20,000 on auditors, because customers kept asking for reassurance. The most upvoted reply was blunt: "Don't. You are exactly the wrong kind of firm to be pursuing SOC2." Others said buyers had accepted questionnaires, a penetration test or a promise to certify later, and one said a self hosted option removed the requirement. A few small teams said they had done it with tooling and a smaller audit firm.

Both camps are right. A report bought before any customer needs it is wasted money, but the underlying controls are worth having, and a founder who has them can get a report quickly when a deal requires one.

There is a second pressure. One SBOM guide for SaaS startups lists newer SOC 2 auditors as a trigger for SBOM requests and maps an SBOM to change management evidence under CC8.1 and, partly, to monitoring under CC7.1, while noting it does not satisfy those criteria alone. Dependency tracking belongs in your first batch of controls. See do you need an SBOM for SOC 2.

What a SOC 2 Type 2 report actually is, and what the AICPA text says

SOC 2 is an attestation report, not a certificate. The AICPA describes its SOC offerings as "a suite of service offerings CPAs may provide" over system level controls at a service organization. The report is issued by a licensed CPA firm, and the AICPA sets the professional standards those firms follow. The full title of the AICPA's SOC 2 guide names the five trust services categories the examination can cover: security, availability, processing integrity, confidentiality and privacy. Security is the category nearly every report includes; the others are added when your commitments to customers make them relevant.

A Type 2 report has three main parts you will care about:

1. Management's description of the system and management's assertion. You write this. It explains what your service does, its infrastructure, software, people, procedures and data, and which controls you rely on.
2. The service auditor's opinion. The CPA firm says whether the description is fairly presented, whether controls were suitably designed, and, for Type 2, whether they operated effectively throughout the period.
3. Tests of controls and results. For each control, the auditor lists what they tested, how many samples, and any exceptions found.

The AICPA publishes an illustrative SOC 2 Type 2 service auditor's report updated for SSAE 21, which applies to reports dated on or after 15 June 2022. It labels that example "nonauthoritative," so treat it as a guide to structure rather than a rule.

What I could not read. The authoritative texts sit behind a free AICPA account login, and I could not open them for this post: the 2017 Trust Services Criteria (With Revised Points of Focus, 2022), the 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022) and the full illustrative Type 2 report. Where this post refers to specific criteria such as CC5.1, CC7.1 or CC8.1, those references come from secondary sources that summarise the criteria, and you should confirm the exact wording in the AICPA documents (a free account is enough) or with your auditor before relying on it.

Can one person satisfy segregation of duties, code review and access review?

Yes, but not by pretending a second person exists. Auditors are used to small service organizations. What they will not accept is a policy that describes a review process nobody performs. Here is how each of the three hard controls works when the company is one person.

Segregation of duties

Segregation of duties means the person who makes a change should not be the only person who approves and releases it. Secondary summaries of the trust services criteria describe a point of focus under CC5.1 that addresses cases where separating incompatible duties is not practical and calls for alternative control activities instead. Points of focus are guidance, not mandatory checklist items, so the auditor judges whether your alternative addresses the same risk.

A Warren Averett article on the "SOC 2 catch 22" for small companies describes the exact situation: one or two people handle development, deployment and approval, and it suggests "Secondary review, documented approvals or shared oversight" as mitigations. For a solo founder that translates to three practical alternatives:

• The machine is the second party. Tests and dependency and container scans must pass before code merges, and the founder cannot turn them off without leaving a trace. The control is "no change reaches production unless an automated gate has passed, and changes to that gate are logged."
• An outside person reviews on a schedule. A fractional CTO, advisor or contract engineer reviews a sample of merged changes monthly, or every high risk change, and records it.
• Management review of logs. The founder reviews deploy, access and alert logs on a fixed cadence. Weak alone, but useful alongside immutable logs and an outside reviewer.

Code review

GitHub's documentation is direct on one point: "Pull request authors cannot approve their own pull requests." So a solo founder who turns on "require one approval" will block every merge unless someone else reviews. Two honest patterns work:

• Require a pull request with zero required approvals, plus strict required status checks. Every change goes through a pull request, so there is a record, and nothing merges unless CI, tests and security scans pass. The ruleset blocks force pushes and direct pushes to the default branch, and nobody is on the bypass list.
• Require one approval from an outside reviewer for high risk paths. Use a CODEOWNERS file so that changes to authentication, billing, infrastructure as code or the CI workflow itself need the outside reviewer, while ordinary changes merge on green checks.

There is a useful twist for automated pull requests. When a bot or an AI remediation system opens a dependency upgrade, the founder who reviews and merges it is genuinely a different party from the author. Whether your auditor treats that as sufficient is their call, so describe it plainly.

Access review

Access review asks who and what can reach production and customer data, and whether each grant still makes sense. With one human, the human side is short. The machine side is not: cloud IAM roles, deploy keys, CI tokens, OAuth apps on the code host, third party API keys and database users are where access goes stale.

A quarterly access review is a dated record listing every account and credential in your critical systems, its purpose, and whether you kept, reduced or removed it, built from raw exports the auditor can inspect. Commands are in the step by step section.

How auditors handle the one person case

• Scope. If you hired nobody during the period, there is no hiring population to test, but you still need a documented process for when you do.
• Subservice organizations. Your cloud provider and code host run many controls you depend on. Reports usually carve them out and list complementary subservice organization controls, which readers check in the provider's own SOC report.
• Complementary user entity controls. Controls your customers must run, such as managing their own users in your app. Listing them clearly narrows what you claim.
• Exceptions. A few documented exceptions with clear remediation are normal. A control that never operated is much worse.
• Qualified opinions. If a required control was missing all period, the auditor may qualify the opinion, so fix design gaps before the window starts.

Type 1 or Type 2 first, and how long is the observation window?

A Type 1 report covers whether controls were suitably designed and implemented as of a single date. A Type 2 report covers whether they operated effectively throughout a period. The AICPA material I could read does not fix a minimum length. BD Emerson describes a Type 2 window as "usually three to twelve months," and Warren Averett gives "over six months to a year" as an example. Ask your buyer what they accept before you choose. The calendar times below are rough planning figures, not sourced numbers.

With a live deal, a common sequence is Type 1, then a short Type 2 window starting right after, then annual twelve month reports. If you already have months of automated evidence, ask the auditor about going straight to a short Type 2. Between reports, buyers often ask for a bridge letter, a letter from you stating that nothing material has changed since the report period ended.

What does it cost a one person company in money and time?

The most specific public numbers I found come from BD Emerson, a firm that sells SOC 2 audit and readiness services, so read them as a seller's ranges.

The Ask HN target of under $20,000 is plausible for audit fees alone with a narrow scope (security only, a short window, cloud provider carved out), and hard once you add a penetration test and tooling.

Time matters more than money for one person. Readiness means several focused days over a month or more: policies, branch protection, CI gates, risk assessment, vendor list, logging, backups and the system description. During the window, recurring reviews take an hour or two a week if evidence is automated, far more if it is screenshots. Fieldwork usually costs several days of answering requests.

Which controls are hard to evidence alone?

Some criteria assume more than one person. These cause the most trouble for solo founders.

Change management. The auditor samples changes and checks each was authorized, tested and approved before release. Direct pushes, console hotfixes and hand run database changes are the usual exceptions. Route every change, including infrastructure and configuration, through a pull request and a pipeline, and define an emergency procedure with an after the fact review recorded within a set number of days. Secondary sources report that the 2022 points of focus added patch management under CC8.1, so dependency and image updates should flow through the same path.

Peer review. The trap is a policy saying "all code is peer reviewed" when nobody reviews. Write what actually happens: automated gates for all changes, outside review for high risk paths, periodic sampled review.

HR controls. Most HR populations are empty for a company of one. You still need a code of conduct you have acknowledged, dated security training, an onboarding and offboarding checklist ready for the first hire, and confidentiality terms with contractors. Contractors are your population, and the auditor will sample them.

Governance. The criteria describe board level oversight. Many small companies document a periodic management review, often with an advisor present. Ask the auditor how they will treat this before the window starts.

Incident response, vendors and risk. With no incidents, the test is usually a tabletop exercise, run with an advisor and recorded. Keep a vendor list and review each critical vendor's SOC report yearly. Keep a dated risk register with owners and treatments, reviewed at least annually.

Compensating controls that hold up for a one person company

A compensating control has to address the risk the missing control would have covered, and it has to produce evidence the auditor can sample. "I am careful" is not a control. These hold up well:

Two cautions. An outside reviewer whose contract lapses mid window leaves you with exceptions. And the auditor decides whether a compensating control is enough, so agree the approach in writing during readiness.

What vulnerability management evidence must a small team show?

Here a solo founder can look as mature as a much larger company, because nearly all of it can be automated. Secondary summaries place vulnerability detection under CC7.1 and patch handling under CC8.1. Expect requests for the following; our post on what SOC 2 requires for vulnerability management goes deeper on each item.

1. A written policy with timelines. For example, critical within 7 days, high within 30, medium within 90, with a defined exception process. Pick timelines you can actually meet alone. Our guide on how fast a startup should patch dependencies for SOC 2 has a defensible starting point.
2. Scanning coverage. Dependency and container image scans of everything you deploy, on every pull request and on a schedule so new advisories against old code get caught.
3. A record per finding. Detection date, severity, whether it is reachable, the decision (fix, accept, not affected) and closure date. A dated fix pull request is ideal evidence.
4. Proof the timelines were met. The auditor samples findings and checks closure dates against your policy; a missed deadline without a documented exception becomes a report exception.
5. Risk acceptance records. A dated note with the reason, compensating measures and a review date.
6. An external test. Penetration testing is not named as a requirement in the material I could read, but many auditors and buyers expect a recent one.
7. An SBOM per release. Not required by SOC 2, but it answers "how do you track open source components" in one file.

On a budget, see free or paid vulnerability tooling for solo developers.

When are a security packet and questionnaire answers enough?

Often, at the start. A security packet is a short set of documents you send instead of, or before, a report: a security overview, your key policies, an architecture and data flow summary, your subprocessors list, the results summary of a recent penetration test, and your answers to a standard questionnaire. Add a dated statement of where you are on SOC 2, such as "Type 1 readiness complete, audit scheduled for Q1," only if it is true.

Questionnaire answers deserve the same care as a report, because they become contract representations. Answer what you do today, not what you plan. "We align with SOC 2 controls but have not completed an audit" is honest; "we are SOC 2 compliant" without a report is not, and the Journal of Accountancy, the AICPA's magazine, notes that "compliance" is not a term used in SOC 2 examinations.

Step by step: build a solo founder control stack this week

These steps assume GitHub and a common cloud provider; adapt the commands to your stack. Each step produces evidence you can hand to an auditor later.

Step 1. Protect the default branch with a ruleset that even you cannot bypass.

cat > ruleset.json <<'EOF'
{
  "name": "default-branch-protection",
  "target": "branch",
  "enforcement": "active",
  "bypass_actors": [],
  "conditions": { "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] } },
  "rules": [
    { "type": "deletion" },
    { "type": "non_fast_forward" },
    { "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 0,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": true,
        "require_last_push_approval": false,
        "required_review_thread_resolution": true
      } },
    { "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": true,
        "required_status_checks": [
          { "context": "test" },
          { "context": "dependency-scan" }
        ]
      } }
  ]
}
EOF
gh api --method POST repos/OWNER/REPO/rulesets --input ruleset.json

Required approvals stay at zero because authors cannot approve their own pull requests. Code owner review is on so files assigned to an outside reviewer need their approval; confirm this on a test pull request, and if your plan does not enforce it at zero approvals, set approvals to one and have the outside reviewer approve every change. The empty bypass list means the ruleset applies to you too.

Step 2. Assign high risk paths to an outside reviewer.

# .github/CODEOWNERS
/.github/workflows/    @your-outside-reviewer
/infra/                @your-outside-reviewer
/src/auth/             @your-outside-reviewer
/src/billing/          @your-outside-reviewer

The reviewer needs write access to the repository for their approval to count. Give them the narrowest role that works and include them in your access review.

Step 3. Gate every pull request on tests and dependency checks.

# .github/workflows/ci.yml
name: ci
on:
  pull_request:
  push:
    branches: [main]
  schedule:
    - cron: "0 6 * * 1"
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm audit --omit=dev --audit-level=high
      - uses: safeguard-sh/gold-scan-action@v1
        with:
          fail-on: kev

The job names match the required status checks in Step 1. The weekly schedule catches new advisories against code that has not changed. Start the Gold scan with fail-on: kev (fail only on known exploited vulnerabilities) and move to vuln once your backlog is clean. For Python, swap in pip install pip-audit && pip-audit -r requirements.txt; for Go, go install golang.org/x/vuln/cmd/govulncheck@latest && govulncheck ./....

Step 4. Scan locally and keep an SBOM per release.

safeguard scan --dir .                 # repository dependencies
safeguard scan --image myapp:1.4.2     # the image you deploy
safeguard scan --sbom sbom.cdx.json    # an SBOM you already have
ls ./output                            # JSON results to keep with the release

Store the JSON output and the SBOM with each tagged release. That gives you a dated record of what shipped and what was known about it.

Step 5. Export change management evidence every month.

mkdir -p evidence/$(date +%Y-%m)
gh pr list --state merged --base main --limit 500 \
  --json number,title,author,mergedAt,reviews,statusCheckRollup \
  > evidence/$(date +%Y-%m)/merged-prs.json
gh api repos/OWNER/REPO/rulesets > evidence/$(date +%Y-%m)/rulesets.json

The first file shows every change, its checks and any reviews. The second proves the protection was in place. Run it monthly so the populations exist when the auditor asks.

Step 6. Run a quarterly access review from raw exports.

gh api orgs/YOUR-ORG/members --paginate > evidence/access/github-members.json
gh api repos/OWNER/REPO/collaborators --paginate > evidence/access/github-collaborators.json
gh api repos/OWNER/REPO/keys > evidence/access/deploy-keys.json
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode \
  > evidence/access/aws-credential-report.csv
aws iam list-roles --query 'Roles[].RoleName' > evidence/access/aws-roles.json

Then write a one page record: date, every human and machine identity, its purpose, the decision (keep, reduce, remove), and links to the changes you made. Have your outside reviewer read and initial it, which adds a second set of eyes to a control you otherwise perform alone.

Step 7. Test a restore and run a tabletop.

Restore last night's database backup to a scratch environment, confirm row counts against production, record start and end times, and delete the scratch copy. Once a year, walk through a realistic incident with an advisor and write down what you would change.

What to prepare now so the audit is cheap later

The biggest driver of audit cost for a small company is evidence reconstructed by hand. Everything below is cheap now and expensive in fieldwork.

1. Write the system description early. One to three pages on what the service does, where it runs, the data it holds and the providers you depend on.
2. Adopt short, true policies. Security, access, change, vulnerability, incident response, backup and continuity, vendors, retention, acceptable use.
3. Turn on the automated gates now. Every month of protected, green checked pull requests is evidence you will not have to explain.
4. Calendar the recurring tasks with a record template. Quarterly access review and restore test, monthly vulnerability review, and annual risk assessment, policy review, vendor review, tabletop and training.
5. Sign the outside reviewer with a written scope and cadence before the window starts.
6. Choose the auditor on quality, not speed. In May 2026 the AICPA issued a peer review alert telling reviewers to scrutinise high volume SOC 2 practices whose reports, risk assessments and sample sizes look identical across clients; the AICPA's Carl Mayes said "Some firms are leaning too heavily on third-party SOC platforms." In February 2026 the chair of the AICPA SOC 2 Working Group warned that "fast and easy" may cost quality and objectivity. Ask firms about peer review results, sampling and how they tailor reports.

For the general startup sequence, see how to get SOC 2 for a startup. If you ship AI features, read what auditors ask AI companies.

Where Safeguard fits, and where it does not

For a solo team, automation has to act as the reviewer you do not have. Safeguard is tooling that customers use for exactly that part of the job:

• Scans on every change. Dependency and container image scanning of repositories, images and SBOM files on push, on a schedule or on release, matched against NVD, GHSA, OSV and CISA KEV, with reachability analysis to rank what your code actually calls.
• Fix pull requests without a second engineer. Griffin autonomous remediation opens tested, policy gated pull requests to a fixed version, authored by the system and merged by you, which leaves dated evidence for your patch timelines. It ships switched off, with every category set to Manual.
• Policies and gates. Gates can block, warn, notify or require approval in CI, so "no known exploited vulnerability ships" is enforced by configuration, not memory.
• A compliance workspace. Frameworks including SOC 2, with controls, evidence, monitoring, tests, policies, risks, vendors and connectors that collect evidence from connected systems, plus help drafting questionnaire answers for you to review. The public Trust Center page is newer and in early access.

Where it does not help: Safeguard is not a CPA firm and does not issue SOC 2 reports or opinions. It cannot be the human second party for segregation of duties, it does not run your background checks or HR process, and it does not replace a penetration test or the judgment your auditor applies to your compensating controls.

Common mistakes

• Buying the audit before any customer asks. You pay yearly for a report with no deal attached.
• Policies that describe a team you do not have. "Reviewed by a second engineer" is a guaranteed exception with no second engineer.
• Making yourself a bypass actor. A ruleset the founder can bypass is not a compensating control.
• Screenshots instead of exports. Keep dated JSON or CSV exports the auditor can sample.
• Forgetting machine identities such as deploy keys, CI tokens and OAuth apps in access reviews.
• Buying the cheapest, fastest report without asking your target buyer what they accept.
• Letting the outside reviewer lapse mid window, which creates an exception for every missing month.
• Saying "SOC 2 compliant" or "certified." Say you have a SOC 2 Type 2 report for a stated period, or that an audit is in progress.

FAQ

Can a one person company get SOC 2 at all?

Yes. There is no headcount minimum. You need a defined system, controls that address the trust services criteria, and evidence they operated. The work is showing alternatives to segregation of duties.

Do auditors accept a solo founder approving their own code?

Not on its own, and GitHub does not let authors approve their own pull requests anyway. Auditors are more likely to accept unbypassable automated checks, outside review for high risk changes and periodic sampled review. Agree the approach before the window starts.

Should I get SOC 2 Type 1 or Type 2 first?

If a buyer needs something soon, Type 1 first, then a short Type 2. If no buyer is waiting, build controls first and start the audit when one is.

How long is the SOC 2 Type 2 observation period?

The AICPA material I could read sets no fixed minimum. Small companies commonly use three to twelve months, often shorter for a first report.

How much does SOC 2 Type 2 cost for a startup?

One firm that sells these services quotes $12,000 to $45,000 in audit fees at startup scope and $30,000 to $90,000 all in for year one. Get quotes for your actual scope.

Is SOC 2 worth it for a solo founder?

When a specific deal or a pipeline of similar deals requires it and covers the cost, yes. As a speculative badge, no. The controls are worth building either way.

What can I send customers instead of a SOC 2 report?

A security packet: overview, key policies, architecture summary, subprocessors, penetration test summary, completed questionnaires and an honest statement of audit plans.

Does SOC 2 require an SBOM?

Not by name in any material I could read, but an SBOM per release is strong change management evidence and some auditors and buyers now ask for one. See do small companies need an SBOM.

What is a bridge letter?

A letter from the service organization stating nothing material has changed since the last report period ended, used to cover the gap until the next report.

Fix it without waiting for upstream

For a one person company, patch timelines are a SOC 2 control you cannot hand to a colleague, so the fix has to come to you rather than wait in a backlog. The same three tools apply to every vulnerable dependency that shows up during your observation window.

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

To try the tools, install the CLI from safeguard.sh/download and follow the CLI documentation.

The first demo is a real CLI session. You ask the assistant to fix a lodash vulnerability, it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For a solo founder, that approval prompt is the point: every change is proposed, tested and accepted by you, which is the record your change management evidence needs.

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

The second demo sets up the Safeguard runner on your own machine, approves it with a device code, and then runs a scan from the terminal. A one person company can use the same flow to produce dated scan results per release without standing up separate infrastructure.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude may use. When a questionnaire asks how you handle a specific vulnerability, you can ask your assistant to look up the finding in your account while you keep control of what it can reach.

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

Quick check

Sources

• AICPA: SOC 2, SOC for Service Organizations topic page
• AICPA: System and Organization Controls, SOC suite of services
• AICPA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022), download page (full text requires a free account)
• AICPA: SOC 2 Description Criteria, download page (full text requires a free account)
• AICPA: Illustrative Service Auditor's SOC 2 Type 2 Report (SSAE 21)
• Journal of Accountancy: AICPA guides peer reviewers to address SOC 2 risks (May 2026)
• Journal of Accountancy: Promises of "fast and easy" threaten SOC credibility (February 2026)
• Warren Averett: The SOC 2 catch 22 that holds small companies in place
• BD Emerson: How much does SOC 2 cost?
• GitHub Docs: Available rules for rulesets
• GitHub Docs: Approving a pull request with required reviews
• Hacker News: Ask HN, can a solo founder become SOC 2 Type 2 compliant?
• Cybersecify: SBOM management for SaaS startups

Last reviewed: 23 October 2026. SOC 2 guidance and AICPA oversight of SOC practices are changing in 2026; confirm criteria wording with the AICPA documents and your auditor.