SOC 2 Compliance: A Practical Engineering Guide

By Kokil Thapa | Last reviewed: September 2026

Enterprise buyers ask for a SOC 2 report before they wire transfer six figures. That makes SOC 2 Compliance: A Practical Engineering Guide less about legal paperwork and more about how your Laravel app, Ubuntu servers, and GitLab pipelines behave under audit. I've shipped client portals with document storage and payment flows where access control and logging were non-negotiable from day one. This page maps AICPA Trust Service Criteria to concrete engineering tasks you can implement on a small team—without hiring a compliance department first. If you already run production systems, you are closer to readiness than most founders assume.

Start with the sibling overview at SOC 2 compliance for startups if you need business context. Engineers should treat readiness like compliance as code: policies live in Git, controls run in CI, and proof is exported automatically rather than scraped from Slack at quarter-end.

What is SOC 2 compliance and who actually needs it?

SOC 2 is an attestation framework published by the AICPA. An independent CPA firm examines whether your organisation's controls meet selected Trust Service Criteria. Security (CC) is mandatory. Availability, processing integrity, confidentiality, and privacy are optional categories you choose based on what you sell.

SaaS vendors, API platforms, payment-adjacent tools, and any B2B product handling customer data routinely face SOC 2 requests. Nepal-based SaaS selling globally hits the same bar as a Bay Area startup. Local IRD and VAT rules still apply for billing, but SOC 2 answers the buyer's question: "Can we trust your engineering?"

The official framework lives on the AICPA SOC 2 resources page. Read the description criteria once. Then translate each CC family into tickets your team can close.

When SOC 2 beats other frameworks

ISO 27001 certifies a management system. SOC 2 produces a customer-shareable report US enterprises expect. GDPR governs personal data rights in the EU. Many teams pursue SOC 2 first because procurement teams attach it to vendor security questionnaires. For Nepal companies serving international clients, pairing SOC 2 readiness with data residency and compliance planning avoids surprises later.

How do you map SOC 2 controls to everyday engineering work?

Auditors sample evidence that policies exist and controls operate consistently. Your job is to make both visible in systems engineers already touch. On production Laravel applications I maintain, that means RBAC via Spatie Permission, encrypted secrets in environment files outside Git, and audit logs for admin actions.

Break the Common Criteria (CC) into engineering domains:

1. CC6 Logical access: MFA on GitLab, AWS, and production SSH. Role-based app permissions. No shared admin accounts.
2. CC7 System operations: Centralised logging, alerting on failed logins, patch cadence documented.
3. CC8 Change management: Pull requests required, CI checks, tagged releases, rollback runbooks.
4. CC9 Risk mitigation: Vendor inventory, annual access reviews, backup restore tests.

Minimum viable control set for a Laravel SaaS on Ubuntu

You do not need Kubernetes to pass SOC 2. A well-run LAMP-style stack on Ubuntu with GitLab CI and Deployer 7 can satisfy auditors if evidence is clean. Document these baselines:

• PHP 8.3 or 8.5 on production, with Composer 2.10 lockfile committed.
• Separate staging and production environments with distinct credentials.
• Redis 8.10 or database sessions with secure cookie flags.
• Nightly encrypted database dumps tested quarterly.
• Admin actions logged to an append-only table or external log sink.

Client portals like Mijar Law Associates need document access trails. That maps directly to CC6 and confidentiality criteria. Build logging before the auditor asks who downloaded which file.

What technical evidence do SOC 2 auditors expect from engineering teams?

Evidence is the product of SOC 2 compliance work. Auditors request populations—lists of changes, users, incidents—and sample items from each. Missing one population delays the report by weeks.

Maintain an evidence matrix linking control ID, system source, export command, and retention period. Store exports in a dated folder structure your CPA can browse read-only.

Align incident documentation with an incident response playbook. Auditors want timestamps, impact, root cause, and remediation—not heroic Slack threads.

Sample export commands your pipeline can run

Automate read-only exports. Never give auditors production shell access.

# GitLab: export project members (run in CI on schedule)
curl --header "PRIVATE-TOKEN: $GITLAB_RO_TOKEN" \
  "https://gitlab.example.com/api/v4/groups/42/members/all" \
  | jq '.' > evidence/$(date +%Y-%m)/gitlab-members.json

# AWS: IAM credential report (requires iam:GenerateCredentialReport)
aws iam generate-credential-report
aws iam get-credential-report --output text > evidence/$(date +%Y-%m)/iam-credentials.csv

# Laravel: artisan audit of admin role assignments
php artisan tinker --execute="echo User::role('admin')->pluck('email');" \
  > evidence/$(date +%Y-%m)/app-admins.txt

Pair exports with a strong password policy enforced via your identity provider and application-level MFA for privileged routes. Weak credentials fail CC6 even when everything else looks polished.

How do you automate SOC 2 compliance evidence in CI/CD?

Manual evidence collection breaks the moment someone goes on leave. Treat compliance exports as scheduled CI jobs with the same seriousness as deployment pipelines. I've used GitLab CI on shared EC2 infrastructure for multiple production sites; the same pattern applies to SOC 2 automation.

Read the dedicated walkthrough at automate SOC 2 compliance evidence in CI. The core idea: nightly or weekly jobs write JSON and CSV artefacts to an S3 bucket with versioning and object lock.

GitLab CI job skeleton for evidence export

soc2-evidence-export:
  stage: compliance
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - mkdir -p "evidence/${EVIDENCE_MONTH}"
    - ./scripts/export-gitlab-members.sh > "evidence/${EVIDENCE_MONTH}/gitlab-members.json"
    - ./scripts/export-composer-audit.sh > "evidence/${EVIDENCE_MONTH}/composer-audit.json"
    - aws s3 sync evidence/ s3://company-soc2-evidence/${EVIDENCE_MONTH}/ --sse AES256
  artifacts:
    paths:
      - evidence/
    expire_in: 1 year

Add security scanning stages to your existing pipeline. Composer audit catches vulnerable PHP packages. npm audit covers Vite 8.x frontend builds. Fail builds on critical CVEs in production branches.

For teams building pipelines from scratch, compare patterns in Jenkins CI/CD tutorials and Azure DevOps YAML pipelines. The scheduler differs; the evidence outputs should not.

Infrastructure checks as code

Use Terraform for infrastructure as code where possible. Auditors love drift detection. A weekly `terraform plan` that exits non-zero on unexpected changes proves CC8 change control extends to cloud resources.

Server hardening belongs in Ansible or cloud-init scripts checked into Git. Document UFW rules, SSH key-only auth, and automatic security updates on Ubuntu. Linux system administration work and SOC 2 readiness overlap heavily—patching and logging are the same tickets.

Centralise application logs per log aggregation for small teams. CC7 expects you to detect and respond to anomalies. You cannot prove monitoring with `tail -f` on one server.

Should you pursue SOC 2 Type I or Type II first?

Type I reports on control design at a specific date. Type II reports on operating effectiveness over a period—usually six to twelve months. Enterprise buyers increasingly demand Type II. Type I is a reasonable milestone if a deal deadline is tight.

Realistic readiness timeline for a ten-person team

Months 1–2: gap assessment, policy drafts, MFA everywhere, logging baseline. Months 3–4: CI evidence jobs, access review process, backup restore test. Months 5–6: observation window begins; no control regressions. Month 7+: Type II fieldwork with CPA firm.

Budget Rs 800,000–2,500,000 (~USD 6,000–19,000) for a first Type II audit depending on scope and firm. Engineering time often exceeds audit fees. Factor that into enterprise application development estimates when SOC 2 is on the roadmap.

Common engineering mistakes during observation

• Granting temporary production access that never gets revoked.
• Skipping CI on "tiny" hotfixes during a customer emergency.
• Rotating API keys without updating the vendor inventory spreadsheet.
• Disabling alerts because they were noisy instead of tuning thresholds.

Each mistake becomes a Type II exception. Exceptions do not always fail the report, but they extend fieldwork and erode buyer confidence.

How does SOC 2 fit with platform engineering and vendor management?

SOC 2 is not a one-time project. It is an operating mode. Platform teams embed control checks into golden paths: new services inherit logging, scanning, and backup policies by default. That aligns with platform engineering principles without requiring a dedicated internal developer platform on day one.

Vendor management satisfies CC9. Maintain a spreadsheet or CMDB entry for every subprocessors: hosting provider, email API, payment gateway, error tracker. Review their SOC 2 reports annually. If you integrate Stripe, PayPal, eSewa, or Khalti, document data flows and retention.

For custom builds, engage teams who treat testing and optimization and support and maintenance as ongoing control operation—not a launch-week checkbox. SOC 2 rewards boring consistency.

Security testing references like the OWASP Application Security Verification Standard help you prioritise fixes auditors notice. Map ASVS Level 1 items to your Laravel middleware, CSRF protection, and session configuration.

NIST guidance on security and privacy controls (NIST SP 800-53 Rev. 5) offers deeper vocabulary if your enterprise customers ask how SOC 2 maps to their internal frameworks. You do not implement all of NIST for SOC 2, but crosswalk documents impress security reviewers.

Key Takeaways

• SOC 2 compliance is an engineering operating model—map CC6–CC9 to access, logging, change control, and risk workflows you already run.
• Collect evidence automatically via scheduled CI jobs; auditors sample populations, not hero narratives.
• Type II requires months of consistent operation—start exports before the observation window opens.
• MFA, RBAC, encrypted backups, and incident postmortems cover a large share of first-audit findings.
• Pair SOC 2 readiness with vendor reviews and log aggregation so controls survive team turnover.
• Treat policies as code in Git alongside Terraform, Ansible, and pipeline YAML.

People Also Ask

How long does SOC 2 Type II take?

Most startups need six to twelve months of observation after initial remediation. Add six to ten weeks for CPA fieldwork and report drafting. Starting evidence collection early shortens the calendar even if remediation runs in parallel.

Can a small development team pass SOC 2 without dedicated compliance staff?

Yes. Teams under fifteen engineers pass Type II regularly when founders assign a control owner and automate exports. The burden is consistency, not headcount. A part-time security champion plus scheduled CI jobs beats a compliance hire with no Git access.

What is the difference between SOC 2 and ISO 27001?

SOC 2 produces an attestation report focused on Trust Service Criteria for service organisations, common in US SaaS procurement. ISO 27001 certifies an information security management system under accredited bodies, more common in EU and global enterprise contracts. Many companies pursue both over time; engineering controls overlap significantly.

Do Nepal-based SaaS companies need SOC 2?

Not legally, unless a specific contract requires it. International B2B buyers frequently request SOC 2 before signing. Local tax and registration rules remain separate; see eCommerce legal compliance in Nepal for domestic obligations that run parallel to vendor security reviews.

Build SOC 2 readiness into your next release

SOC 2 Compliance: A Practical Engineering Guide boils down to provable controls: who accessed production, what changed, how you detected failure, and how fast you fixed it. Implement MFA and logging this sprint. Schedule evidence exports next sprint. Pick Type I or Type II based on deal pressure, then stay consistent through the observation window.

If you want help hardening a Laravel application, Ubuntu infrastructure, or CI pipeline before an audit, review our custom software development services or contact us with your stack and target report date. Read more on the blog, browse the portfolio, or explore developer tools for day-to-day engineering work.