How to Audit Your Software Architecture for SOC 2 and GDPR

What Auditors Actually Look For

SOC 2 and GDPR audits feel opaque until you understand what the auditor's job is: they are verifying that your security controls are real and operational, not just documented.

For SOC 2 Type II, the criteria most relevant to software architecture:

• CC6.1 — Logical access controls: Is access to data restricted by role? Is multi-tenancy enforced at the system layer, not the UI layer?
• CC6.2 — Authentication controls: Is password hashing current (bcrypt/argon2)? Is MFA available? Are sessions properly invalidated on logout?
• CC6.7 — Data transmission controls: Is all data in transit encrypted? Are API endpoints using TLS?
• CC7.2 — System monitoring: Is there an audit trail for data access and modifications?
• CC8.1 — Change management: Are infrastructure changes tracked? Is there a documented deployment process?

For GDPR, Article 25 (Data Protection by Design and by Default) requires that privacy controls are built into the system from the start — not added afterward. An auditor will ask: how do you know your system implements data minimisation? Where is the documentation that privacy was considered in the design phase?

Vibe-coded apps typically fail CC6.1 (no tenant isolation), CC7.2 (no audit trail model), and GDPR Article 25 (no design-phase privacy documentation) on first assessment.

What an Architecture Audit Produces

The Archiet architecture audit at archiet.com/audit-my-architecture is a 15-minute process that produces:

1. A scored architecture report (0–100) across five dimensions: entity completeness, auth posture, multi-tenancy enforcement, compliance alignment, and documentation quality
2. A gap list — specific, named issues with the architecture (not general recommendations)
3. A compliance section — for each applicable framework, which controls are satisfied and which are gaps
4. An evidence pack — documentation you can provide to an auditor: the architecture model, the control mapping, the design decisions

Step 1: Describe or Upload Your Architecture

At archiet.com/audit-my-architecture:

Option A — Describe your system (5 minutes): Answer the wizard questions about your entities, data types, auth mechanism, and compliance obligations. You do not need a pre-existing document.

Option B — Upload your spec (2 minutes): Upload a PRD, architecture document, ERD, or any structured description. Archiet extracts the architecture from the document. Supported formats: PDF, DOCX, Markdown, plain text.

Option C — Connect your repository (if you have the integration): Archiet analyses your actual codebase and infers the architecture from the code. More accurate than description, reveals drift between stated architecture and actual implementation.

Step 2: Review the Audit Output

The audit returns within 30–60 seconds. The report has three sections:

Architecture score with dimension breakdown:

Overall: 62/100

Entity completeness:      18/25   Tenant isolation on Task missing
Auth posture:             15/25   Password reset flow absent; tokens in localStorage
Multi-tenancy:            10/20   organization_id present on User, absent on Resource
Compliance alignment:     12/20   SOC 2 CC6.2 gap: no MFA. GDPR: no data retention policy
Documentation quality:     7/10   No ADRs present

Gap list (specific and actionable):

• Resource entity missing organization_id foreign key — tenant isolation not enforced on resource access
• Auth tokens stored in localStorage — SOC 2 CC6.1 gap (client-side token exposure); fix: httpOnly cookies
• No password reset flow detected — SOC 2 CC6.2 requirement
• No audit trail model — SOC 2 CC7.2 requirement; need audit_log table with actor, action, target, timestamp
• No data retention policy — GDPR Article 5(1)(e) requirement

Each gap includes a reference to the specific control requirement and an Archiet fix (what the generated replacement would include to close the gap).

Step 3: What to Give Your Auditor

From the audit output, Archiet produces three documents for your auditor:

Architecture overview (ARCHITECTURE.md format): A consulting-grade architecture document: executive summary, system map, key decisions, NFR posture, risks, and phased roadmap. This is the document that answers "describe your system architecture" in an audit.

Control mapping: A table mapping each SOC 2 criterion (or GDPR article) to the specific architectural control that satisfies it — with traceability to the code. "CC6.1 satisfied by organization_id FK on all 7 tenant-scoped entities, enforced in app/models/base.py."

Gap remediation plan: For each gap, the specific change required, the priority, and (if you regenerate with Archiet) which generated files address it.

This is not documentation about your intent. It is documentation about your actual architecture, produced from the model that generated your code.

Step 4: Use the Blueprint to Regenerate With Controls Built In

If the audit reveals systemic issues (missing tenant isolation, no audit trail, client-side tokens), the fastest fix is to regenerate from the corrected model:

1. In the Blueprint editor, fix the gaps the audit identified:

- Add organization_id to missing entities - Switch auth to httpOnly cookies - Add the SOC 2 or GDPR overlay

1. Click Generate
2. The generated codebase now has the controls built in:

- Every entity is tenant-scoped - Auth uses httpOnly cookies and refresh token rotation - An audit_log model and logging service are generated - The GDPR DPIA is populated from your actual entity model

The migration from your existing database to the generated schema is handled by the Alembic migrations. The audit trail model is additive — it adds a new table without changing existing tables.

Common Questions

"We already passed a SOC 2 Type I. Does this help for Type II?" Type I assesses whether controls exist. Type II assesses whether they operated effectively over a period (typically 6–12 months). The audit trail model that Archiet generates is the operational evidence for Type II — it logs access, changes, and authentication events continuously. Start collecting that evidence now.

"Our system is not vibe-coded, it is a 5-year-old Rails monolith. Does this apply?" Yes. The architecture audit works on any system. Upload your current documentation (or describe the system). The audit identifies the same gaps regardless of how the code was written. The remediation path is different (targeted fixes rather than regeneration), but the evidence pack for your auditor is the same.

"Our auditor wants to see the actual controls, not documentation about them." Correct — and the generated code is the evidence. app/models/audit_log.py is the audit trail control. app/blueprints/auth_bp.py with httpOnly cookie handling is the CC6.2 control. The code is the evidence; the documentation traces the auditor to it.

---

The SOC 2 attestation process takes 6–12 months. The architecture audit takes 15 minutes and tells you exactly what you need to fix before that process starts. Do the audit first.