The deal was almost done. A mid-market company loved your Laravel product, the champion had budget approval, and the contract was sitting in legal. Then procurement sent over a security questionnaire with 240 questions, and question three asked: "Please attach your most recent SOC 2 Type II report." You don't have one. The deal doesn't die, but it stalls, and every week it sits in review is a week your competitor with a report in hand looks safer to buy from.
If you're a small Laravel team, this is almost always how SOC 2 enters your life. Not through regulation, not through a security incident, but through a sales blocker. And the way it's usually explained, by auditors, for auditors, makes it sound far more mystical than it is. Strip away the vocabulary and SOC 2 is a structured way of answering one question: can you prove that you actually operate the security controls you claim to operate?
The good news is that a well-run VPS-based Laravel stack already produces most of the evidence an auditor wants. Key-only SSH, firewall rules, git history, deploy logs, automated backups, monitoring alerts: these aren't compliance artifacts bolted on later, they're the exhaust of running production responsibly. The hard part isn't doing the work. It's capturing proof that you did it, continuously, for months.
This post walks through SOC 2 the way we'd want it explained to us as engineers: when you actually need it, what evidence maps to what criteria, where teams get caught out (restore drills, offboarding), and what a realistic timeline looks like for a team of two to ten people.
Key Takeaways- SOC 2 is an AICPA framework audited by licensed CPA firms; only the Security criterion is mandatory in scope. - Type I assesses control design at a point in time; Type II proves operation over a 3-12 month window. - Auditors want evidence, not claims: restore logs beat backup configs, access reviews beat access policies. - A hardened VPS Laravel stack already generates most required evidence if you capture it.
What Is SOC 2, and When Does a Laravel SaaS Actually Need One?
SOC 2 is an attestation framework created by the AICPA, the American Institute of Certified Public Accountants. It is not a certification you self-declare and not a government regulation. A licensed CPA firm examines your controls and issues a report stating whether those controls are designed properly and, for Type II, whether they operated effectively over an observation period.
The framework is built on five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Only Security is mandatory. The other four are optional scope you add based on what your customers care about. Most small SaaS companies start with Security alone or Security plus Availability, because those are the two that enterprise procurement teams actually ask about. Adding Privacy or Processing Integrity expands the audit surface considerably, and unless your buyers demand it, there's little reason to volunteer for it in year one.
So when do you need it? Honestly: when sales tells you that you do. SOC 2 is an enterprise sales gate, not a legal requirement. If you sell to individual developers and small agencies, nobody will ever ask. The moment your average contract value climbs into the range where procurement departments get involved, the questionnaires start, and "we take security seriously" stops being an acceptable answer. If you're seeing security questionnaires on more than one deal per quarter, or a specific large deal is blocked on it, that's your signal. Before that point, your time is better spent on the underlying security work itself, which is why we'd point any Laravel team at a production security checklist long before an audit is on the calendar. Everything you fix now becomes evidence later.
One more thing worth internalizing early: SOC 2 doesn't prescribe specific technology. There is no rule that says "use AWS" or "use this framework." The auditor evaluates whether your controls meet the criteria, not whether your stack matches some enterprise template. A Laravel monolith on a well-managed VPS can pass the same audit as a Kubernetes fleet, and often with a cleaner story, because there's less surface to explain.
Type I or Type II: Which Report Should You Get First?
The two report types answer different questions, and the difference matters more than most first-timers realize.
Type I
Type II
What it assesses
Control design at a single point in time
Control operating effectiveness over a period
Observation window
None (snapshot date)
Typically 3-12 months
Auditor asks
"Do these controls exist and make sense?"
"Did these controls actually run, every time, all period?"
Evidence burden
Policies, configurations, one-time screenshots
Continuous logs, tickets, reviews, drill records
Time to obtain
Weeks after readiness
Observation window plus audit time
Weight with enterprise buyers
Moderate; often accepted as a bridge
Strong; the default procurement ask
Typical use
First-year milestone while Type II window runs
The report you renew annually
Type I
Strengths: Fast to obtain once your controls are designed and documented. Gives sales something real to attach to a questionnaire within weeks instead of months. Forces you to write down policies and close obvious gaps.
Best for: Teams with an enterprise deal stalling right now who can't wait out an observation window, or teams using it as a forcing function to get their house in order.
Considerations: Sophisticated buyers know a Type I only proves your controls existed on one day. Some procurement teams accept it as a bridge with a committed Type II date; others won't. Budget-wise you're paying for two audits in your first year if you do both.
Type II
Strengths: The report buyers actually want. Proves your controls operated over a real window, which is a fundamentally stronger claim. Renewing it annually becomes routine once evidence collection is automated.
Best for: Teams that can start their observation window now and close enterprise deals in six to twelve months, or teams whose buyers have explicitly said Type I won't cut it.
Considerations: The observation window is a minimum wait, not a formality. A control that lapsed for three weeks mid-window becomes an exception in your report. You need evidence discipline for the entire period, which is exactly where compliance automation platforms earn their fee.
The pragmatic path we see most small teams take: start the readiness work immediately, open a Type II observation window as soon as controls are stable, and optionally grab a Type I along the way if a specific deal demands paper sooner.
What Infrastructure Evidence Do Auditors Actually Ask For?
Here's the part nobody explains well. Auditors don't inspect your servers. They request evidence: exports, logs, screenshots, tickets, and records that demonstrate each control operated. For a VPS-based Laravel stack, the mapping looks like this.
Trust Services Criterion
In scope?
Concrete infrastructure evidence from a Laravel VPS stack
Security
Mandatory
SSH key inventories, firewall rules, fail2ban logs, patching records, access review sign-offs, deploy logs, encrypted secrets configuration
Availability
Common add-on
Uptime monitoring history, alert logs, backup schedules, restore drill records, incident post-mortems, rollback records
Confidentiality
Common add-on
Encryption-at-rest evidence, TLS configuration, access scoping by role, data classification notes
Processing Integrity
Rare for small SaaS
Job queue monitoring, data validation controls, reconciliation records
Privacy
Rare; overlaps GDPR
Data retention schedules, deletion records, subprocessor list, server location documentation
If you've already done GDPR work, some of this will feel familiar; our post on GDPR for Laravel developers covers the data-location and deletion side, and that documentation is reusable if you ever add Privacy to scope. Now let's go domain by domain through what the Security and Availability criteria actually demand from your infrastructure.
Access Control: Who Can Touch Production, and How Do You Know?
This is the first thing every auditor probes, and the first place small teams fail. The questions are simple. Who has SSH access to production? How is it granted? How is it revoked when someone leaves? Can two people be told apart in your logs?
The engineering answers are ones you should already have: key-only SSH with password authentication disabled, no shared root credentials, one key per human, and a defined offboarding step that removes keys and platform access on the person's last day. The evidence answers are the exports that prove it. A dump of authorized_keys entries mapped to named people. A record showing the departed contractor's key was removed within your stated window. Quarterly access review sign-offs where someone actually looked at the list and confirmed everyone on it still belongs there.
Shared accounts are the classic finding here. If three engineers all log in as deploy with the same key, your logs can't attribute actions to individuals, and the auditor will flag it. Individual keys plus a platform layer with per-user accounts and roles solves this cleanly. Offboarding is the second classic finding: teams that have never once removed an ex-employee's access, because nobody ever left before, discover mid-audit that they have no process and no record.
Change Management: Can You Show How Code Reaches Production?
Auditors want to see that changes to production are authorized, reviewed, and traceable. If you're using git with pull requests, you already run a change management system; you just haven't been calling it that.
Your git history is the change record. PR reviews are the authorization step. Deploy logs, with timestamps, the deploying user, and the commit deployed, tie the change record to production. Rollback capability is your answer to "what happens when a change goes wrong," and a log showing you actually rolled back a bad deploy is better evidence than any policy paragraph about rollback procedures.
What trips teams up: direct pushes to main with no review, hotfixes applied by SSHing in and editing files on the server (which bypasses the entire change record), and deploys with no log of who triggered them. The fix isn't process theater. It's making the pipeline the only path to production and letting the pipeline's own logs be your evidence.
# A surprising amount of change-management evidence is one command away
git log --merges --since="2026-01-01" --pretty=format:"%h %an %ad %s" --date=short
# Show that branch protection forces review (GitHub CLI)
gh api repos/OWNER/REPO/branches/main/protection --jq '.required_pull_request_reviews'
Vulnerability Management: How Do Patches Actually Happen?
The control here is a patching routine that runs whether or not anyone remembers it. On Ubuntu, that means unattended security upgrades, and the evidence is the configuration plus the logs showing it ran.
# Confirm unattended upgrades are enabled
cat /etc/apt/apt.conf.d/20auto-upgrades
# APT::Periodic::Update-Package-Lists "1";
# APT::Periodic::Unattended-Upgrade "1";
# Evidence that it has actually been running
grep "Packages that will be upgraded" /var/log/unattended-upgrades/unattended-upgrades.log | tail -20
On the application side, composer audit checks your dependency tree against known advisories, and running it in CI on every build turns it from a good habit into a logged, recurring control:
composer audit --format=json > audit-$(date +%F).json
Keep the outputs. A folder of dated audit results showing you scanned weekly and remediated findings is exactly the kind of evidence that makes a Type II observation window painless. Auditors also like to see that findings go somewhere: a ticket that says "bumped guzzlehttp/psr7 for advisory X, deployed on this date" closes the loop from detection to fix to production.
Backup and Recovery: Auditors Want Restore Evidence, Not Backup Evidence
Read that heading twice, because this is the single most common gap we see. Teams show auditors a backup schedule and a bucket full of dumps and consider the control satisfied. The auditor's next question: "Show me the last time you restored one."
A backup you've never restored is a hypothesis. The control auditors actually care about is recoverability, and the evidence is a restore drill record: a dated log showing someone pulled a backup, restored it to a scratch database, verified row counts or ran the test suite against it, and recorded how long it took. Do this quarterly, write down the date, duration, and outcome each time, and you've turned twenty minutes of work into some of the strongest Availability evidence in your report.
# A minimal quarterly restore drill, logged
aws s3 cp s3://backups/db/latest.sql.gz ./drill/ --endpoint-url $S3_ENDPOINT
gunzip drill/latest.sql.gz
mysql -h 127.0.0.1 restore_drill < drill/latest.sql
mysql -h 127.0.0.1 restore_drill -e "SELECT COUNT(*) FROM users; SELECT MAX(created_at) FROM orders;"
echo "$(date -u +%FT%TZ) restore drill OK, 14m22s, verified users+orders tables" >> drills.log
Retention matters too: state a retention policy (say, 30 daily backups) and be able to show the bucket actually reflects it. If you want the full setup, our guide on automated database backups covers schedules, retention, and off-server storage; the drill habit is what upgrades that setup from good practice to audit evidence.
Monitoring and Incident Response: What Happens When Things Break?
The Availability criterion wants proof that you detect problems and respond to them in a structured way. Three artifacts cover most of it: monitoring with alert history, a written incident response playbook, and post-mortems for incidents that actually happened.
Alert history is the underrated one. A log of every alert fired over the observation window, with timestamps showing when it fired and when it resolved, demonstrates that your monitoring is real and that someone responds. A playbook doesn't need to be long; ours fits the shape we described in the incident response playbook for server outages: detect, triage, communicate, fix, review. What matters to an auditor is that it exists, names roles, and that your post-mortems reference it.
And here's a counterintuitive tip from the trenches: incidents help your audit. A team with two documented incidents, each with a post-mortem and a follow-up fix, tells a stronger story than a team claiming a spotless record with no evidence their process has ever been exercised. Don't hide your outages from the auditor. Show them the paper trail.
Encryption: In Transit, at Rest, and in Your Secrets
The expectations here are unambiguous. TLS on every public endpoint, with certificates that renew automatically. Secrets not sitting in plaintext in a repo or a shared doc. Backups encrypted before they land in object storage. Provider API tokens and SSH private keys encrypted at rest wherever they're stored.
For a Laravel app, the secrets story deserves specific attention because .env files are the soft underbelly of most stacks. Laravel's encrypted environment files (php artisan env:encrypt) and a defined process for who can read production secrets go a long way; we wrote up the full approach in secrets management for Laravel. Evidence-wise, the auditor wants your TLS configuration (an SSL Labs result or certificate inventory works), your encryption-at-rest description for the database and backups, and your answer to "who can see production credentials, and how is that access logged?"
The firewall and intrusion-prevention layer rounds out the Security picture, and the evidence is literally command output:
ufw status verbose
# Status: active
# Default: deny (incoming), allow (outgoing)
# 22/tcp ALLOW IN Anywhere
# 80,443/tcp ALLOW IN Anywhere
fail2ban-client status sshd
# |- Currently banned: 3
# `- Total banned: 412
That Total banned counter, captured monthly, is a tidy little proof that the control isn't just configured but actively working.
The Gap Between "We Do This" and "We Can Prove We Do This"
Every domain above has the same failure mode. The engineering is done, the control operates, and yet the audit is painful, because nothing was captured. Closing that gap is mostly about building three habits before your observation window opens, not after.
First, prefer pulled evidence over posed evidence. A screenshot of a firewall config proves the config existed the moment you took the screenshot. A log exported from an API proves the control operated over time, can't be quietly staged, and doesn't require a human to remember anything. Wherever your infrastructure can emit evidence programmatically, wire that up; save screenshots for the handful of things that have no export. This is also the core value proposition of compliance automation platforms like Vanta, Drata, and Secureframe: they connect to your systems and collect evidence continuously so the observation window documents itself.
Second, run quarterly access reviews and write them down. Fifteen minutes, four times a year: list everyone with production access, SSH keys, database credentials, and admin roles in your platform tooling; confirm each person still needs it; remove what's stale; record who reviewed and when. This single ritual satisfies a surprising number of audit requests, and it's the ritual most teams skip because "we're only four people, we know who has access." The auditor doesn't know that, and in a year you won't remember either.
Third, keep policies short and true. You will need written policies: information security, access control, change management, incident response, business continuity. The temptation is to download a 40-page template and adopt it wholesale. Resist it. Auditors test whether you follow your policies, so every aspirational sentence you didn't need becomes a control you can fail. A two-page policy that accurately describes what your team actually does will serve you better than an impressive binder describing a company you aren't. Write down reality, then improve reality, then update the document.
If you want a structured way to find the gaps before an auditor does, a self-run security audit of your own servers is the closest thing to a dress rehearsal: every item you verify is an item you now know how to evidence, and every item you can't verify just told you where your first exception would come from.
How Deploynix Features Double as Audit Evidence
We built Deploynix as a provisioning and deployment platform, not a compliance product. But somewhere around the third customer who asked us for evidence exports, we realized that a platform which manages your servers is, almost by accident, an evidence collection system. Here's the honest mapping.
Access control. Deploynix teams have organization roles, so "who can deploy to production" is a defined, reviewable list rather than tribal knowledge, and the quarterly access review becomes reading one screen. Servers are provisioned with key-only SSH from day one, so there's no password-auth finding waiting to happen.
Audit trail. Every server action taken through the platform, provisioning, deploys, config changes, is recorded in server logs with the acting user and timestamp. That's the attributable, per-person action history the access control and change management criteria both lean on.
Change management. Deploys are logged with commit, user, and time, which turns each release into a change record that reconciles against your git history. Zero-downtime deploys with rollback give you the "what happens when a change is bad" answer, and a rollback that actually happened is sitting right there in the deploy log as evidence.
Vulnerability management. Unattended security upgrades are enabled by default on provisioned servers, alongside UFW in deny-by-default mode and fail2ban. The hardened baseline isn't something you configure for the audit; it's the starting state.
Backup and recovery. Automated database backups run on schedule to S3-compatible storage with retention, giving you the schedule and retention evidence directly. The restore drills are still on you, and they should be; no platform can honestly automate away the act of verifying your own recoverability.
Monitoring. Server monitoring keeps alert history with 30-day metric retention, so "show me your alerting worked during the window" is an export rather than an archaeology project.
Encryption. Provider credentials and SSH private keys are encrypted at rest in the platform, which is one line in your confidentiality narrative you don't have to build yourself.
Everything above is also reachable through the API, which matters more than it sounds: when your auditor or your compliance automation platform asks for evidence, a scripted export beats an afternoon of screenshots every single time. None of this makes you SOC 2 compliant on its own; no tool does. It means the infrastructure layer of your evidence list is largely handled, and your remaining work concentrates on policies, reviews, drills, and the application layer.
How Long Does It Take, and What Does It Cost?
Plan in months, not weeks, and plan for two cost centers: the auditor and the tooling.
A realistic sequence for a small Laravel team looks like this. One to two months of readiness work: hardening gaps, policies, access reviews started, evidence collection wired up. Then the Type II observation window opens, typically three months for a first report (buyers sometimes discount a three-month window; six or twelve carries more weight on renewal). During the window, your job is simply to keep the controls running and the evidence flowing. After the window closes, the CPA firm performs fieldwork and writes the report, which adds several more weeks. End to end, six to nine months from "we should do this" to a Type II PDF in the sales team's hands is a sane expectation. Teams that need paper sooner slot a Type I in after readiness.
On cost, we'll stay general rather than quote numbers that vary widely by firm and scope: you're paying a licensed CPA firm for the audit itself, usually annually, plus a subscription if you use a compliance automation platform. Together they're a meaningful line item for a small company, which is exactly why the trigger should be real enterprise demand rather than ambient anxiety.
Compliance automation platform (Vanta, Drata, Secureframe)
Strengths: Continuous, API-pulled evidence collection; policy templates; auditor marketplaces; dramatically less manual gathering during the window.
Best for: Teams going for Type II who want the observation window to document itself, and teams without a dedicated compliance person, which is every small team.
Considerations: A real recurring cost, and the templates still need editing down to your reality. The platform collects evidence; it doesn't operate your controls for you.
Manual evidence collection
Strengths: No subscription cost. Forces deep familiarity with your own controls. Viable for a Type I with narrow scope.
Best for: Teams testing the waters with a Type I, or teams whose auditor provides a simple evidence request list and whose stack is small.
Considerations: For a Type II window, manual collection means months of remembering to capture things on schedule. One forgotten month is an exception in your report. Most teams that start manual switch before renewal.
What Do Auditors Not Care About?
Knowing what's out of scope saves real anxiety, so let's clear a few things up.
They don't care that you use Laravel. Framework choice is invisible to the criteria. Nobody loses points for PHP, and nobody gains points for Rust. The auditor cares whether changes are reviewed, dependencies are scanned, and secrets are protected, in whatever stack you run.
They don't care which cloud or VPS provider you use. DigitalOcean, Hetzner, AWS, a European provider chosen for data residency: all fine. What they'll ask for is your subprocessor list and your providers' own compliance reports (major infrastructure providers publish these), which slot into your evidence as inherited controls.
They don't care that your team is small. There's no minimum headcount for SOC 2. Small teams do face specific friction, like separation of duties when the person writing code is also the person approving deploys, but auditors handle this constantly and there are accepted compensating controls, like logged self-review with after-the-fact spot checks.
And they don't care about perfection. A report can include exceptions and still be valuable; a noted exception with a documented remediation reads as a functioning program, not a failing one. The report is a narrative of how you operate, not a pass/fail exam with a trophy at the end.
FAQ
Do we need SOC 2 if we're a two-person Laravel startup?
Not until your buyers ask for it. SOC 2 is a sales instrument, not a legal obligation. Do the underlying security work now, start keeping evidence habits early because they're cheap, and pull the trigger on an audit when enterprise questionnaires start arriving or a specific deal is gated on a report.
Can we pass SOC 2 on a VPS, or do we need a big cloud provider?
You can absolutely pass on a VPS. The criteria are provider-agnostic; auditors evaluate your controls, not your vendor's logo. You'll list your infrastructure provider as a subprocessor and reference their compliance documentation, then evidence your own layer: access, patching, backups, monitoring, and change management.
Type I first or straight to Type II?
If no deal is burning, go straight for Type II: start the readiness work, open a three-month observation window, and you'll have the stronger report in roughly two quarters. If a deal is stalled today, a Type I plus a committed Type II date is a common and often accepted bridge.
What's the most commonly missing piece of evidence?
Restore drills. Nearly every team can show backups exist; far fewer can show a dated record of restoring one and verifying the data. Quarterly drills with a one-line log entry each are the cheapest audit win available. Second place goes to offboarding records and quarterly access reviews.
Does using Deploynix make us SOC 2 compliant?
No, and be wary of any tool that claims otherwise. Deploynix gives you a hardened default baseline and exportable evidence for the infrastructure layer: action logs, deploy history, backup schedules, alert history. Policies, access reviews, drills, and the audit itself remain your work with a CPA firm.
Where to Start This Week
You don't start SOC 2 by calling an auditor. You start it by making your infrastructure provably boring: attributable access, logged changes, automatic patching, tested restores, and monitoring with a paper trail. Everything in this post compounds; evidence habits started this quarter are observation-window gold next year, and every gap you close is one less finding when a CPA firm finally looks.
If you do one thing this week, make it a dry run: work through a step-by-step security audit of your server, and for every control you verify, ask the auditor's question instead of the engineer's one. Not "does this work?" but "could I prove this worked in March?" The distance between those two answers is your entire SOC 2 project, measured honestly, before anyone bills you for the measuring.
Top comments (0)