SOC 2 Type II Compliant Software Engineering & Custom ERPs

Enterprise Security Systems: SOC 2 Type II Compliance Architecture

Executive Summary

This is the control set ERPStack builds into custom ERPs headed for a SOC 2 Type II examination. A Type II report differs from a Type I in one decisive way: it tests whether controls operated effectively over a period, typically 3 to 12 months, rather than whether they existed on a single day. Evidence therefore has to accumulate by itself for the whole window. Systems that depend on someone remembering to take a screenshot fail this, and they fail it late.

The Five Trust Services Criteria, in Code

Security, the common criteria: a Web Application Firewall filters ingress, CORS allow-lists are explicit rather than wildcarded, and PostgreSQL runs in a private subnet with no public route. RBAC is evaluated in the API layer on every query — never trusted from the client.

Availability: multi-AZ deployment on AWS with automated failover, plus alerting on CPU, memory, and connection-pool saturation. The design targets 99.9% availability; what your contract commits to is a commercial decision, not an engineering one.

Processing Integrity: input validated with Zod schemas at the boundary, multi-step writes wrapped in ACID transactions in PostgreSQL. Records are processed completely or not at all — there is no partial-write path to reconcile later.

Confidentiality: contracts, financials, and intellectual property restricted to named roles. Uploads land in private AWS buckets with server-side encryption and short-lived signed URLs.

Privacy: consent state is a first-class column, and a data subject can export or delete their own records through the same REST API the support team uses.

CI/CD as a Control

Automated gates generate the change-management evidence a Type II window needs. Semgrep SAST scans the TypeScript codebase on every commit for injection and unsafe deserialisation. Dependency audits fail the build on a high-severity match rather than warning. Merges to the release branch require a reviewed pull request, and GitHub Actions retains the run history, so approvals, tests, and scans exist as dated artefacts.

// Server-side authorisation. RBAC is re-checked on every request:
// a client-supplied role claim is an assertion, the PostgreSQL row is the fact.
import { headers } from 'next/headers';

export async function verifySoc2SecurityContext(requiredRole: string): Promise<boolean> {
  const reqHeaders = await headers();
  const authHeader = reqHeaders.get('authorization') ?? '';
  if (!authHeader.startsWith('Bearer ')) {
    return false;
  }
  const token = authHeader.slice(7); // verify the JWT signature, then re-read
  return verifyRoleInDatabase(token, requiredRole); // the role from PostgreSQL
}

Infrastructure Safeguards

Every SOC 2 oriented deployment uses one isolation pattern. PostgreSQL is reachable only through the application role or a bastion host with session recording. Connection strings and API keys live in a cloud vault, injected at runtime through workload identity, so no engineer holds standing production credentials and there is no standing access to review. Terraform describes all of it, so an auditor reads infrastructure change history as pull requests. Log monitoring alerts on unusual export volume, bulk reads, and repeated authentication failures, with thresholds tuned per tenant rather than globally.

Operational Outcomes

Enterprise sales cycles shorten because a security questionnaire is answered with architecture documents instead of promises. Least-privilege RBAC and append-only logs limit both blast radius and time to detect. And the evidence a CPA firm samples already exists, dated, across the entire observation window — which is the difference between a 2-week fieldwork exercise and a 2-month scramble.

Stack and Boundaries

Custom ERPs for a SOC 2 examination run on Next.js and TypeScript with PostgreSQL behind Drizzle ORM, deployed by Terraform into your own AWS account. RBAC is enforced in the Next.js API layer; Redis caches only non-confidential data; Zod validates 100% of API boundaries; SSO handles identity. Semgrep SAST, Vitest, and Playwright run in GitHub Actions on every commit, and Sentry carries the error telemetry. ERPStack operates 0 of it: after handover no ERPStack account reaches your PostgreSQL cluster or your AWS keys, which removes us from the SOC 2 boundary entirely.