One tool for
SOC 2, HIPAA, ISO 27001 & GDPR

The compliance overlap problem

Most SaaS companies serving enterprise customers face multiple compliance requirements simultaneously. A healthcare SaaS company might need SOC 2 Type II for enterprise sales, HIPAA for handling patient data, ISO 27001 for European customers, and GDPR for any EU data subjects. Each framework has its own audit process, evidence requirements, and terminology — but the underlying security controls overlap significantly.

The opportunity is to recognise this overlap and build security practices that satisfy all four frameworks simultaneously, rather than running four separate compliance programmes.

SOC 2 — Trust Services Criteria

SOC 2 is an auditing standard developed by the AICPA. It evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy. For software companies, the Security Trust Services Criterion (CC series) is mandatory; the others are optional.

Key SOC 2 controls for engineering

• CC6.1 — Logical access controls: Authentication, authorisation, and access provisioning/deprovisioning. Requires MFA for privileged access.
• CC6.6 — Logical access restrictions: Network segmentation, firewall rules, and restricting access over public internet to minimum necessary.
• CC7.1 — System monitoring: Detection of anomalies, logging, alerting. Requires SIEM or equivalent.
• CC7.2 — Vulnerability management: Scanning for vulnerabilities, tracking remediation, and testing. This is where SAST/DAST/SCA directly contribute to SOC 2 evidence.
• CC8.1 — Change management: Code review, testing, and approval before production deployment. CI/CD pipeline controls.

HIPAA — Technical Safeguards

HIPAA's Security Rule applies to covered entities and business associates handling Protected Health Information (PHI). The Technical Safeguards section (45 CFR § 164.312) specifies requirements for access controls, audit controls, integrity, and transmission security.

Key HIPAA technical requirements for engineering

• § 164.312(a)(1) — Access control: Unique user identification, emergency access procedures, automatic logoff, encryption and decryption of ePHI.
• § 164.312(b) — Audit controls: Hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI.
• § 164.312(c) — Integrity: Electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorised manner.
• § 164.312(e) — Transmission security: Encryption of ePHI in transit. TLS 1.2+ for all data containing PHI.

ISO 27001 — Annex A Controls

ISO 27001:2022 is an international standard for information security management systems (ISMS). Certification requires an independent audit against both the management system requirements and the Annex A controls.

Annex A controls relevant to application security

• A.8.25 — Secure development life cycle: Security requirements integrated into the development process from design through deployment.
• A.8.26 — Application security requirements: Security requirements specified, reviewed, and approved for applications.
• A.8.28 — Secure coding: Documented secure coding principles applied, code reviewed for security, SAST tooling in CI/CD.
• A.8.29 — Security testing in development and acceptance: Penetration testing, vulnerability scanning, DAST before production deployment.
• A.8.8 — Management of technical vulnerabilities: Timely identification, evaluation, and remediation of technical vulnerabilities. Requires a documented vulnerability management programme.

GDPR — Article 32: Security of Processing

GDPR Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Unlike prescriptive standards, GDPR is risk-based — you must demonstrate that your security controls are appropriate for the data you process.

Article 32 technical measures for engineering teams

• Pseudonymisation and encryption of personal data at rest and in transit.
• Confidentiality, integrity, availability, and resilience of processing systems — availability and disaster recovery planning.
• Ability to restore availability and access to personal data after a physical or technical incident — backup and recovery testing.
• Regular testing, assessing, and evaluating the effectiveness of technical and organisational measures — the explicit mandate for vulnerability scanning and penetration testing.

A unified approach to all four frameworks

The key insight is that the technical controls required by all four frameworks converge around the same set of practices:

Technical Control              SOC 2    HIPAA    ISO 27001    GDPR
─────────────────────────────────────────────────────────────────
SAST / code scanning           CC7.2    §164.312  A.8.28      Art.32
DAST / API testing             CC7.2    §164.312  A.8.29      Art.32
Secret scanning                CC6.1    §164.312  A.8.28      Art.32
SCA / dependency scan          CC7.2    §164.312  A.8.8       Art.32
Encryption at rest             CC6.7    §164.312a A.8.24      Art.32
Encryption in transit          CC6.7    §164.312e A.8.24      Art.32
Access control / MFA           CC6.1    §164.312a A.5.15      Art.32
Logging / audit trail          CC7.1    §164.312b A.8.15      Art.32
Vulnerability management       CC7.2    implict   A.8.8       Art.32

Generating audit evidence automatically

The most time-consuming part of compliance audits is gathering evidence — screenshots, reports, logs, and records that demonstrate controls were operating effectively during the audit period. Automated tooling dramatically reduces this burden.

• Scan reports as evidence: Every SAST/DAST/SCA scan produces a timestamped report showing what was scanned, what was found, and the severity classification. This is direct evidence for vulnerability management controls.
• Remediation tracking: Linking scan findings to ticket remediation with timestamps demonstrates that vulnerabilities are being actioned within SLA — a core requirement of CC7.2 and A.8.8.
• Continuous scanning: Evidence of continuous (not point-in-time) scanning demonstrates operational effectiveness of controls throughout the audit period, not just before the audit.
• Policy enforcement: CI/CD pipeline gates that block deployment on critical findings provide evidence that security requirements are enforced in the development process (CC8.1, A.8.25).

Practical control mapping

When building your compliance programme, map each technical control to all frameworks it satisfies simultaneously. This prevents duplicate effort and ensures your security investment is maximised across audit requirements.