Self-Hosted SOC 2 Compliance: What Your Startup Must Own

Self-hosted SOC 2 compliance software gives your startup control over the GRC workspace, but it also gives your team the operating work that a hosted vendor would otherwise perform. Before choosing it, assign owners for repository access, application security, backups, recovery, upgrades, evidence storage, and incident response. Self-hosting changes who runs the software. It does not operate your controls or replace the CPA examination.

This guide is for a founder or engineer comparing a local or self-hosted workspace with a hosted compliance platform before starting SOC 2. If you first need to decide what software should manage, read the broader open source SOC 2 compliance guide.

TL;DR

• Define what “self-hosted” covers: the application, Git remote, evidence storage, backups, or all four.
• Use a dedicated private repository with named access owners and a tested offboarding path.
• Choose either direct browser saves or a reviewed-branch workflow, then set branch rules that match that mode.
• Keep credentials and sensitive records out of ordinary Git history.
• Back up the repository and any external evidence store, then test restoration.
• Assign an owner for security updates and model migrations.
• Keep source systems responsible for identity, cloud, endpoints, monitoring, training, signatures, and other control operation.
• Confirm scope and evidence decisions with a qualified CPA firm.

What self-hosted SOC 2 compliance software means

“Self-hosted” is incomplete unless the vendor or project names each component. A startup may run the interface on a laptop, store the repository with a Git provider, keep large evidence files in object storage, and use a separate backup service. That is a different risk and recovery model from running every part on one internal server.

Document where each part runs:

Component	Question to answer
Application runtime	Which device or server runs it, and who patches it?
Program repository	Which Git service or server stores the authoritative branch?
Identity and access	How do people gain, review, and lose access?
Evidence storage	Which files stay in Git, and which remain in approved source systems?
Backup	What is copied, where is it kept, and who can restore it?
Automation	Which CI jobs or agents can read or change the workspace?
Audit delivery	How will management prepare and send approved records to the CPA firm?

Open source, local-first, and self-hosted describe different properties. Open source concerns source access and licensing. Local-first software remains useful on a local device. Self-hosting means your company operates some or all of the service. Check each property instead of treating the labels as interchangeable.

Self-hosting moves work to your startup

Control over the deployment can help a team keep its records in familiar systems and avoid a separate vendor database. It also creates a clear list of jobs your team must own.

Responsibility	What your team must decide and operate
Access	Repository visibility, roles, privileged access, reviews, and removal
Change control	Review rules, validation, merge authority, and emergency changes
Security	Host hardening, dependency updates, network exposure, and secret handling
Resilience	Backup frequency, recovery target, restore testing, and outage response
Retention	Which records and evidence to keep, where, and for how long
Maintenance	Version review, upgrades, model migrations, and rollback plans
Monitoring	Failed jobs, failed pushes, storage limits, and suspicious access
Support	Who diagnoses problems and how quickly the program can recover

Self-hosting does not move every SOC 2 duty into the GRC workspace. Identity, cloud, source control, deployment, endpoint, monitoring, backup, training, signature, procurement, and other source systems still operate their controls and produce source evidence.

The AICPA describes SOC as services that CPAs provide in connection with system-level controls. Management still defines and operates its system. The CPA firm performs the independent examination and decides whether the evidence is sufficient for its work.

Design the repository boundary before adding records

Start with a dedicated private repository for the GRC workspace. Do not mix program history with application development history because access, retention, reviewers, and recovery needs may differ.

Write down:

1. the authoritative branch;
2. the people and service accounts with access;
3. who can approve and merge changes;
4. the validation required before merge;
5. the evidence types allowed in Git;
6. the backup and restoration process;
7. the owner for upgrades and incidents.

If you use GitHub, its protected branch settings can require reviews and status checks and can restrict force pushes or branch deletion. Other Git hosts have their own controls. Configure and test the behavior instead of assuming a private repository supplies it.

Pick the collaboration mode before setting those rules:

Mode	Write path	Branch rule
Browser trunk mode	The local browser validates, creates a commit with local author metadata, and pushes directly to the configured authoritative branch (main by default) with the remote credential	Permit the intended Git-host account or credential, restrict other writers, and do not claim a pull-request review occurred
Reviewed branches	A person or agent uses the CLI or editor on a feature branch, then opens a pull request	Require the intended reviews and validation checks before merge

Do not give a shared browser identity broad bypass authority and call that independent review. If your control requires a separate reviewer, use the reviewed-branch path.

Keep sensitive material out of durable history

Git preserves prior versions, so deleting a secret or sensitive file in a later commit does not remove it from earlier history. Set a written evidence rule before the first collection.

Do not put plaintext credentials, private keys, tokens, recovery codes, or personal data that may need erasure into ordinary Git history. For other evidence, decide whether repository access, encryption, retention, and deletion rules fit the data. Keep high-risk material in an approved source or evidence system and record a stable reference, source, collection date, scope, and review result in the GRC workspace.

Repository scanning can add a detection layer, but it does not replace the content rule. GitHub documents how secret scanning and push protection can alert on or block supported secrets. Check whether the feature is available for your repository type and plan.

Back up the workspace and prove that it restores

A Git remote gives the team another copy, but your recovery plan should still name the records, attachments, configuration, and external evidence needed to resume work. Decide:

• how often backups run;
• where a separate copy is stored;
• who can restore it;
• how keys and credentials are recovered;
• the maximum tolerable data loss and recovery time;
• how often the team tests restoration.

CISA’s backup guidance recommends keeping multiple copies on different media with one copy offsite. Adapt the design to your startup, then record a real restore test. A scheduled backup job proves that a job ran. A restore test proves that the team could use the recovered workspace.

Plan upgrades before the first audit period

Assign one person to watch releases, security notices, dependency changes, and data-model migrations. For each upgrade:

1. read the release and migration notes;
2. create a recoverable backup;
3. run a preview or migration check when the project provides one;
4. apply the change in a reviewable branch or controlled maintenance window;
5. run validation and inspect the diff;
6. verify the application, CLI, CI, and backup path;
7. record the decision and any follow-up.

Do not leave upgrades until fieldwork. An old version may continue to run while its model, dependencies, or documented workflow no longer match the current project. A tested upgrade path is part of the cost comparison with a hosted service.

Keep the local server local

A development server that is safe on a loopback address may be unsafe when exposed to a network. Check authentication, transport security, session handling, network binding, and logging before changing the default exposure.

FileGRC’s editable local server has no built-in authentication, per-user roles, or web-user attribution and binds to loopback by default. An authenticated proxy does not add FileGRC roles: anyone admitted through it can act with the runtime process, local commit metadata, and remote credential. Git author name and email are not the Git-host principal that authorizes a push. Keep the interface on loopback and give each collaborator a local client and individual Git-host access so offboarding can revoke the real account or credential.

If your team still designs a controlled network deployment, terminate TLS at the authenticated layer, bind or firewall the FileGRC port so only that proxy can reach it, limit admission to the intended operator, and test from another machine that direct access to the backend port fails.

Test the self-hosted model before relying on it

Run one short acceptance exercise:

1. Create a test workspace and connect its private remote.
2. Give a test user the intended access, then remove it.
3. Propose a change, review the diff, and run validation.
4. Try an unauthorized or invalid change and confirm it is blocked.
5. Add a permitted evidence sample and reject a prohibited one.
6. Back up the workspace, remove the test copy, and restore it.
7. Upgrade or reinstall the tool from written instructions.
8. Export an approved set of records for a mock CPA request.
9. Record failures, owners, and fixes before adopting the system.

This exercise reveals the labor hidden by the word “self-hosted.” If no one can own the failed-push queue, upgrades, restore tests, or access reviews, use that fact in the software decision.

How FileGRC fits a self-hosted model

FileGRC is an MIT-licensed, Git-native GRC workspace that runs locally. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. The browser, CLI, and CI use the same model and validation rules.

Use a dedicated private repository. In browser trunk mode, the browser uses the configured authoritative branch, which defaults to main in a new workspace. It fetches before a save, validates the change, creates a focused commit, and pushes it to the configured remote. A failed push keeps the local commit for retry. CLI and agent work leave Git operations to the user or agent, so use those paths when a change must go through a reviewed branch.

npx create-filegrc@latest company-grc
cd company-grc
npm run validate
npm run serve

FileGRC does not fetch evidence from external systems, operate your controls, secure your Git host, back up the repository, or perform the examination. Starter records are proposals that management must review and tailor. The FileGRC source and setup guide documents the current behavior and boundaries.

Decide with an ownership test

Choose the self-hosted model only when every operating duty has a named owner, a usable runbook, and a tested recovery path. Compare the full cost of staff time, infrastructure, security, maintenance, and support with the hosted option. The SOC 2 software guide for startups provides a broader evaluation framework.

If the team wants file ownership and reviewable Git changes but cannot operate a shared server, a local application plus a managed private Git remote may be the simpler design. If the team cannot protect or recover the repository, fix that operating gap before putting the SOC 2 program in it.