How to Build Compliance Ready Web Applications that Meet Security and Regulatory Requirements Efficiently

Most web applications are not built for compliance. Compliance gets added to them later. A GDPR audit reveals that personal data is stored without explicit consent records. A PCI-DSS assessment finds that cardholder data flows through a system that was never scoped for payment card security. A SOC 2 Type II audit discovers that logging was incomplete for the twelve months under review.

Retrofitting compliance onto a system that was not designed for it is expensive, slow, and consistently incomplete. Compliance ready web applications are not a luxury reserved for large enterprises. They are the only rational architecture choice for any platform that handles personal data, payment information, or health records.

Secure web application development that accounts for regulatory requirements from the first sprint costs less. It avoids retrofit costs, fines, remediation expenses, and reputational damage.

This guide is for engineering leaders, CTOs, compliance officers, and DevOps teams. Learn how to build compliance ready web applications that satisfy all requirements simultaneously. You'll do it without duplicating work across frameworks.

Five Compliance Frameworks Every Secure Web Application Must Satisfy in 2026

Enterprise web applications rarely face a single compliance requirement. They face several at once. A B2B SaaS platform serving healthcare clients in the United States and enterprise clients in the European Union must satisfy SOC 2, HIPAA, and GDPR simultaneously. A payments platform must satisfy PCI-DSS v4.0 regardless of geography. A global enterprise SaaS company pursuing ISO 27001 certification does so because multinational enterprise clients require it as a procurement condition.

This is not a compliance checklist to work through sequentially. It is a concurrent set of obligations that share substantial technical control overlap and must be addressed through a unified enterprise application security architecture. The good news is that approximately 80% of the technical controls required across all five frameworks overlap. Build the right controls once and satisfy multiple frameworks from a single implementation.

The cost of web application compliance is fixed and predictable when designed up front. Build the technical controls once and maintain them continuously. The annual audit becomes a documentation exercise rather than a remediation project. The cost of non-compliance is variable and unbounded. GDPR fines reach up to 4% of global annual turnover. PCI-DSS failures can result in the loss of card processing ability. SOC 2 failures end enterprise sales conversations before they begin.

No engineering budget item has a more asymmetric risk-reward profile than compliance-by-design.

The Five Core Compliance Frameworks

Understanding each framework's scope, enforcement mechanism, and core technical obligation is essential. These form the foundation of any multi-framework compliance programme.

Here is a concise reference for the five frameworks. Enterprise application security programmes most frequently need to satisfy all of them.

EU General Data Protection Regulation

GDPR applies to any organisation that processes personal data of EU or UK residents, regardless of where the organisation is based. Data Protection Authorities enforce it, with the ICO in the UK, CNIL in France, and the Irish DPA acting as the lead supervisory authority for most US tech companies with EU headquarters. The maximum penalty is €20 million or 4% of global annual turnover, whichever is higher, for the most serious violations. Core technical obligations include Article 5 (data minimisation, purpose limitation, storage limitation), Article 25 (privacy by design and by default), and Article 32 (appropriate technical and organisational measures).

Payment Card Industry Data Security Standard

PCI-DSS v4.0, mandatory for all assessments from March 2025, applies to any entity that stores, processes, or transmits cardholder data. Card brands including Visa, Mastercard, and Amex enforce it through acquiring banks and Qualified Security Assessor audits. The ultimate penalty is losing the ability to accept card payments entirely. Core requirements cover network security, cardholder data protection, secure software development, strong authentication, audit logging, and security testing.

SOC 2 Type II

SOC 2 is the most commercially impactful certification for B2B SaaS companies selling to enterprise clients in the US market. The American Institute of CPAs defines the Trust Services Criteria, and licensed CPA firms perform the audits. There are no regulatory fines. The commercial penalty is losing enterprise customers who require SOC 2 Type II as a condition of doing business. Type II requires demonstrating continuous control operation across a twelve-month observation period, making it the most operationally demanding certification on this list.

Health Insurance Portability and Accountability Act

HIPAA applies to US healthcare providers, health plans, clearinghouses, and their business associates. Any web application that processes, stores, or transmits Protected Health Information falls within scope. The HHS Office for Civil Rights enforces it, with penalties reaching up to $1.9 million per violation category per year. Criminal penalties apply to wilful violations. Core technical obligations come from the Security Rule's Technical Safeguards at 45 CFR §164.312.

ISO 27001

ISO 27001 is a voluntary international standard for Information Security Management Systems, but it functions as a mandatory procurement requirement for many multinational enterprise clients, particularly in government, defence, and financial services. Accredited certification bodies audit organisations at Stage 1 and Stage 2, with annual surveillance audits and recertification every three years. The 2022 revision restructures the standard to 93 controls across four themes, replacing the 114 controls across 14 domains in the 2013 version.

The table below summarises the key attributes of each framework for quick reference.

Framework	Enforced By	Maximum Penalty	Audit Type
GDPR	Data Protection Authorities	€20M or 4% global turnover	Regulatory investigation
PCI-DSS v4.0	Card brands via acquiring banks	Loss of card processing ability	QSA assessment or SAQ
SOC 2 Type II	AICPA / CPA firms	Loss of enterprise customers	12-month observation period
HIPAA	HHS Office for Civil Rights	$1.9M per violation category	Federal investigation
ISO 27001	Accredited certification bodies	Loss of enterprise contracts	Stage 1 + Stage 2 audit

India's DPDP Act 2023 and IT Rules 2021

Indian web applications and global platforms with Indian users face two additional compliance frameworks that complement the five global frameworks above. The Digital Personal Data Protection Act 2023 establishes data protection rights for Indian residents, mirroring GDPR's structure while reflecting the Indian legal context.

The IT (Intermediary Guidelines and Digital Media Ethics Code) Rules 2021 impose platform governance obligations, including grievance management, content moderation, and compliance reporting for Significant Social Media Intermediaries. Organisations building for the Indian market should treat DPDP compliance as a parallel workstream alongside GDPR, not as an afterthought. Most technical controls required for GDPR will satisfy DPDP obligations with minor adjustments to consent management and data localisation architecture.

Compliance by Design: The Architecture Decisions That Determine Compliance Cost

The most expensive compliance programme is the one designed after the platform was built. Every architectural decision made without compliance in mind creates a future remediation obligation. Tables built without data classification require discovery and reclassification. Logging systems added months of events retrospectively. Authorisation models bolted on after launch leave gaps in code paths that were never designed to check permissions.

Compliance-by-design does not add cost to development. It redirects a small portion of architecture decision-making effort in the first sprint toward choices that satisfy compliance requirements from day one. Teams working with web application development services that understand regulatory requirements embed these decisions naturally into the initial architecture phase, avoiding the expensive discovery work that happens later.

The question is not whether compliance will cost time and engineering resources. It will. The question is whether those resources are spent efficiently at the start or inefficiently under audit pressure later.

The Twelve Architecture Decisions That Determine Compliance Posture

These twelve decisions, made in the first sprint, determine how much every future audit will cost. Each one has a clear compliance-by-design choice and a concrete consequence for choosing wrong.

Data Model and Personal Data Identification

Design a data classification taxonomy before writing the first table. Classify every data field as PII, PHI, PAN (payment card data), sensitive, or non-sensitive. Implement classification as database column metadata or as a separate data catalogue record. Tools like AWS Macie or Collibra automate classification for large schemas.

Without this, a GDPR data mapping exercise requires manual review of every database table to identify personal information. For a 50-table schema, that typically costs two to three weeks of combined engineering and legal time, and must be repeated for every new table added over the platform's lifetime.

Multi-Tenancy and Data Isolation

Design tenant data isolation from the first schema. Use separate database schemas per tenant for strong isolation, or a shared schema with tenant_id as a mandatory partition key enforced at the database level using Row-Level Security. Never rely on application-level filtering alone for tenant isolation.

A shared-schema multi-tenant application without RLS relies entirely on the application to filter by tenant_id on every query. A single omitted filter, whether from a development mistake, a code regression, or a SQL injection, exposes all tenants' data to each other. This is simultaneously a GDPR breach and a SOC 2 failure.

Encryption Key Management

Provision AWS KMS Customer Managed Keys or a HashiCorp Vault key hierarchy before any data is stored. Implement envelope encryption for each data classification tier. PII should be encrypted with a different key than PAN. All key access should be controlled by IAM roles and logged to CloudTrail.

An application that stores encrypted data using a hard-coded key, or with the key in the same database as the ciphertext, does not satisfy field-level encryption requirements under any of the five frameworks.

Audit Logging Completeness

Define the audit log schema in the first sprint. Every log entry must contain who took the action, what the action was, and which object it affected, when it occurred in ISO 8601 format with timezone, where it originated from, including source IP and service name, and the outcome. Implement centralised log collection from day one and design logs to be immutable using S3 Object Lock or CloudTrail log file validation.

An audit log that was not designed from the start is incomplete by definition. If the SOC 2 Type II observation period begins before the logging system was operational, that window cannot start. PCI-DSS Requirement 10 requires audit logs covering the entire system.

Consent and Lawful Basis Recording

For GDPR-applicable platforms, design the consent management system before the first user registration. Every processing activity must have a documented lawful basis. Consent records must store the timestamp, the version of the privacy policy consented to, the purpose, and the data subject's identity.

A GDPR audit that finds personal data processed without a documented lawful basis, or consent collected through pre-ticked boxes or vague language, requires a full re-consent exercise. For large user bases, some users will not re-consent, resulting in data that must be deleted.

Data Retention and Deletion Automation

Define retention policies before data accumulates. Each data category needs a defined maximum retention period with automated deletion or anonymisation at the end of it. Design the deletion workflow to satisfy the right to erasure for individual data subjects.

Manual deletion processes are unreliable at scale. A GDPR audit that finds personal data retained beyond the stated retention period is a compliance violation. For HIPAA, retaining PHI beyond the required period is a violation regardless of whether the data was accessed.

Access Control Model

Choose an access control model in the architecture phase. Role-Based Access Control works for most enterprise platforms. Attribute-Based Access Control provides fine-grained resource-level access when needed. Implement the chosen model as a centralised policy engine, such as Open Policy Agent or Casbin, rather than distributed if-checks scattered through application code.

Distributed permission checks cannot be consistently audited. A single missed check is both a Broken Access Control vulnerability and an authorization control failure for SOC 2. A centralised policy engine provides a single point of audit and enforcement.

Network Architecture and Segmentation

Design network segmentation in the first infrastructure sprint. Separate security zones for public, application, data, and management tiers with explicit traffic allowances between zones. Use VPC endpoints for all AWS service access to prevent data from traversing the public internet. Never allow direct internet access from the data tier.

Flat network architecture violates the network segmentation requirements of both PCI-DSS and HIPAA. Retrofitting network segmentation requires updating every service's ingress and egress rules and re-testing all application paths.

Vulnerability Management Programme

Integrate SAST, SCA, and container scanning into the CI/CD pipeline before the first production deployment. Define patching SLAs by severity before the first critical CVE is discovered. Schedule annual penetration testing from the launch quarter.

Organisations leveraging cybersecurity consulting services typically implement these controls as part of their initial architecture engagement, avoiding the large remediation backlog that appears when SAST tools are added to an existing codebase.

Incident Response Planning

Write and test the incident response plan before going to production. Identify the breach notification deadlines for each applicable framework. GDPR requires supervisory authority notification within 72 hours. HIPAA allows 60 days. Most US state data breach laws require notification within 30 to 72 hours, depending on the state.

An organisation that experiences a data breach without a documented and tested incident response plan will almost certainly miss the GDPR 72-hour notification deadline. Missed notification deadlines are an aggravating factor in enforcement decisions.

Third-Party and Supply Chain Risk Management

Conduct vendor security assessments before procuring any service that will process regulated data. Ensure all vendors processing personal data under GDPR have a signed Data Processing Agreement. HIPAA Business Associate Agreements must be in place with all vendors processing PHI before any data flows to them.

Signing a DPA or BAA is not sufficient on its own. The vendor must actually have the required controls. A vendor breach that exposes your users' data is your breach under GDPR. The data controller is responsible for the data processor's compliance.

Compliance Monitoring and Evidence Collection

Implement automated compliance evidence collection from day one. AWS Config records the configuration of every AWS resource at every point in time. CloudTrail logs all API activity. Security Hub centralises compliance findings. Automated evidence collection means the SOC 2 audit becomes a documentation exercise rather than a four-week scramble.

Teams using DevSecOps managed services integrate these monitoring tools into the CI/CD pipeline as a standard delivery component, rather than retrofitting them before an audit deadline.

GDPR Technical Implementation: From Principles to Production Code

GDPR is principle-based legislation. It prescribes outcomes without mandating specific technical implementations. Data minimisation, purpose limitation, storage limitation, accuracy, integrity, and confidentiality are the outcomes required. The implementation must be "appropriate" to the risk profile of the application. This section translates GDPR's principles into specific technical implementations for web application compliance.

Article 25: Privacy by Design and by Default

Article 25 requires that privacy considerations be built into the system architecture, not layered on top after the fact. Five specific technical implementations satisfy this requirement for most web applications.

Data Minimisation at the API Layer

API endpoints should collect and return only the data fields necessary for the specific purpose. Validate API request schemas to reject unexpected fields, which also prevents mass assignment vulnerabilities. Strip non-necessary response fields before returning data. If an endpoint's purpose is to display a user's profile, return the name and avatar, not the date of birth, phone number, or payment details.

Purpose Limitation in the Data Model

Separate database tables or schemas for different processing purposes. Do not use a single users table for authentication, analytics, and marketing. Each purpose has a separate data context with separate access controls. This makes it structurally impossible to use authentication data for marketing purposes, which is what purpose limitation requires.

Default Privacy-Friendly Settings

New user accounts must be configured with the most privacy-friendly defaults. Marketing communications must default to opt-out, not opt-in. Profile visibility should default to private. Location sharing should default to off. Cookies should be set to necessary only until explicit consent is provided for analytics or marketing cookies.

Pseudonymisation for Analytics and Logging

Replace direct identifiers with pseudonymous identifiers in analytics data, logs, and data shared with analytics processors. The pseudonymisation key is stored separately with strict access controls. Analytics data references the pseudonymous ID. Re-identification requires access to both the analytics data and the pseudonymisation key.

Right to Erasure by Design

Design the data model with erasure in mind from the start. Identify which data must be deleted on an erasure request, which must be anonymised but retained for aggregate analytics or accounting, and which is exempt from erasure because law enforcement holds or statutory retention requirements apply.

Article 32: Appropriate Technical and Organisational Measures

Article 32 is where GDPR's security requirements become concrete. Four sub-clauses map directly to specific technical controls.

Article 32(1)(a): Pseudonymisation and Encryption

Pseudonymise data shared with processors, analytics systems, and logs where possible. Enforce TLS 1.2 or higher for all data transmission with HSTS. Implement field-level encryption for PII using AWS KMS or HashiCorp Vault. Full-disk encryption alone does not satisfy this requirement. It does not protect data from a compromised database access credential. Field-level encryption does.

Article 32(1)(b): Ongoing Confidentiality, Integrity, Availability, and Resilience

Confidentiality requires RBAC or ABAC access controls, MFA enforcement, and least-privilege IAM. Integrity requires database change data capture, audit logs of all data modifications, and cryptographic checksums on sensitive records. Availability requires multi-AZ deployment with defined and tested RTO and RPO targets. Resilience requires circuit breakers, graceful degradation, and documented load testing results.

Article 32(1)(c): Ability to Restore Availability After an Incident

Document and test the disaster recovery plan annually. Define RTO and RPO per data classification tier, with shorter targets for PHI and PII than for non-sensitive data. Validate backups. Not just creating backups, but verifying that restores actually work.

Article 32(1)(d): Process for Testing Effectiveness

Run annual penetration tests on all applications processing personal data. Maintain SAST and DAST in the CI/CD pipeline with documented findings and remediation SLAs. Review security control effectiveness annually as part of the ISMS review. Penetration testing services conducted annually satisfy this sub-clause for GDPR as well as PCI-DSS Requirement 11 and SOC 2 CC7.1 simultaneously.

Data Subject Rights: Technical Implementation

GDPR grants data subjects six rights that web applications must support with working technical implementations, not just policy statements.

Right of Access (Subject Access Request)

Build a data export API that returns all personal data held about a specific user in a machine-readable format such as JSON or CSV. The export must include all data fields, processing purposes, retention periods, and recipients. Make the SAR workflow accessible via account settings. Track requests in a case management system to manage the 30-day deadline, which is extendable to 90 days for complex cases with notification

Right to Rectification

Provide users with the ability to correct personal data via account settings. For data that users cannot self-serve correctly, provide a rectification request form. Rectification must propagate to all copies and processors of the data. The response deadline is 30 days.

Right to Erasure

Implement a three-phase account deletion workflow. Phase one is a soft delete from day zero to day 30, marking the account as deleted and pending while retaining it for account recovery. Phase two is a hard delete at day 30, deleting all PII from operational tables, retaining anonymised transaction records for accounting, and notifying all data processors to delete the user's data via API or webhook. Phase three covers backup erasure, with backup copies deleted on the normal rotation cycle, which may take up to 90 days. This is acceptable under GDPR if the backup data is not processed further.

Right to Data Portability

Provide a structured, machine-readable export of all personal data that the user actively provided. JSON or CSV format. Available via API or as a downloadable file in account settings. This is different from the SAR export. Portability covers only data that the user provided, not derived data. The response deadline is 30 days.

Right to Object to Processing

For processing based on legitimate interest or direct marketing, provide a mechanism to object to each processing purpose separately. Record the objection in the consent management system. Cease the relevant processing immediately on receipt of a valid objection. Direct marketing objections must be honoured immediately without requiring a reason.

Right to Restriction of Processing

Implement a processing restriction flag on user records. When set, restrict all processing except storage. The flag must propagate to all systems that process the user's data. Inform the user when the restriction is lifted.

PCI-DSS v4.0 Technical Implementation: Securing the Payment Card Environment

PCI-DSS v4.0 is the most prescriptive of the five compliance frameworks covered in this guide. For web applications that process payment card data, the single most valuable architecture decision is scope reduction. The fewer systems that are in scope for PCI-DSS, the smaller the compliance and audit burden. This is true both for initial certification and for every subsequent annual assessment.

Teams building payment-capable platforms should treat penetration testing services as a required component of PCI-DSS compliance, not an optional add-on. Requirement 11.3 mandates annual penetration testing of all in-scope systems, and the scope of that test is directly proportional to the scope reduction decisions made in the architecture phase.

CDE Scope Reduction Strategies

The Cardholder Data Environment includes every system that stores, processes, or transmits cardholder data, and every system that can affect the security of the CDE. Reducing the number of in-scope systems is the most effective way to reduce compliance cost.

Tokenisation with a Hosted Payment Page

This is the most powerful scope reduction strategy. Replace the in-house payment form with a hosted payment page served by the payment processor. Stripe Elements, Braintree Hosted Fields, and Adyen Drop-in all serve this purpose. The cardholder enters their card details directly on the processor's page inside an iframe or redirect. The merchant's server never receives the raw PAN. Only a token representing the payment method is returned to the merchant's system.

This approach can qualify the organisation for SAQ A, which has 22 requirements compared to 329 for SAQ D. It is not just a compliance simplification. It is a fundamental risk reduction. A database breach exposes no cardholder data because no cardholder data was ever stored.

Server-Side Tokenisation with a Vault

When server-side control is required, call the payment processor's vault API to tokenise the card number. The vault returns a token. Subsequent charges, refunds, and subscriptions use the token. The raw PAN is never stored in the merchant's database. This approach still qualifies for SAQ D but with significantly fewer in-scope components than storing raw PANs.

Network Segmentation

When in-scope systems are unavoidable, segment them from all other systems. The CDE operates as a separate network zone, a separate VPC subnet or AWS account, with strict access controls. Only systems that must communicate with the CDE have network access to it. Validated segmentation reduces both the scope of the QSA assessment and the operational cost of maintaining PCI-DSS controls across fewer systems.

PCI-DSS v4.0 New Requirements

Six significant changes in v4.0, effective March 2025, require specific attention from web application teams.

MFA for All CDE Access (Requirement 8.4.2)

MFA is now required for all access into the CDE from any network location, including internal networks. This extends the previous requirement, which applied only to remote access. All administrative access to CDE servers, database access tools, and CDE-connected systems now requires MFA. AWS IAM Identity Centre with MFA enforced for all CDE AWS account access is the standard implementation.

Phishing-Resistant MFA for Privileged Accounts (Requirement 8.4.1)

FIDO2/WebAuthn or hardware security keys are now required for all non-consumer user accounts with administrative access to the CDE. SMS OTP and software TOTP are no longer sufficient for CDE administrators. WebAuthn binds the credential to the origin domain, making it structurally resistant to phishing attacks. A phishing site cannot steal the authentication credential because the credential is domain-bound.

Disk-Level Encryption Alone Is No Longer Sufficient (Requirement 3.5.1)

v4.0 removes the disk-level encryption alternative for stored PANs. PANs must now be protected by application-layer cryptography. Format-preserving encryption, tokenisation, or strong encryption with separate key management all satisfy this requirement. If your application currently stores PANs protected only by disk-level encryption, migration to application-layer encryption must be completed before the next QSA assessment.

Payment Page Script Management (Requirement 6.4.3)

All scripts loaded on the payment page must be authorised and integrity-checked. This directly targets Magecart-style card-skimming attacks, where unauthorized JavaScript is injected onto payment pages to steal card details. The implementation requires a Content Security Policy with a strict script-src allowlist on payment pages and Subresource Integrity checksums on all third-party scripts.

Automated WAF for All Public-Facing Applications (Requirement 6.4.1)

An automated technical solution must be deployed for all public-facing web applications. AWS WAF, Cloudflare WAF, or an equivalent solution with the OWASP Core Rule Set in blocking mode satisfies this requirement. The WAF must actively maintain rule updates and generate logs reviewed at least daily.

Targeted Risk Analysis

v4.0 introduces the option to perform a Targeted Risk Analysis to justify a different control frequency or approach. This allows organisations to use a customised implementation for many requirements, demonstrating that an equivalent control meets the same security objective. The TRA must be approved by PCI management and reviewed annually.

SOC 2 Type II: Building Twelve Months of Continuous Control Operation

SOC 2 Type II is the most commercially impactful certification for B2B SaaS companies targeting enterprise clients in the US. Unlike SOC 2 Type I, which demonstrates that controls were designed appropriately at a single point in time, Type II requires demonstrating that controls operated effectively for a continuous twelve-month observation period.

This observation period requirement is what makes SOC 2 Type II the most operationally demanding certification on this list. The organisation must not only have the right controls but must demonstrate consistent execution throughout the entire year.

The SOC 2 Trust Services Criteria

Auditors test seven primary areas. Understanding what they test and what evidence they require allows organisations to build the right controls and the right evidence collection processes simultaneously.

CC6.1: Logical and Physical Access Controls

Auditors test whether access controls restrict logical access to authorised users, whether provisioning and de-provisioning processes exist, and access rights are reviewed periodically. Required evidence includes access control policy, user access request and approval records, quarterly access review documentation, and joiners/movers/leavers process records showing that accounts are deactivated within 24 hours of an employee's departure.

The technical control is RBAC with automated de-provisioning triggered by HR system termination events via SCIM provisioning from Workday or BambooHR. Quarterly access reviews conducted as email reminders with manager sign-off, captured in Jira or Confluence, provide the auditor with evidence.

CC6.6: Encryption for Data in Transit and at Rest

Auditors verify that sensitive data is encrypted in transit and at rest, that encryption keys are managed appropriately, and that TLS certificates are valid. Required evidence includes TLS configuration documentation, certificate renewal process evidence, key management procedure, and scan results showing no non-TLS endpoints.

CC7.2: Monitoring for Anomalies and Security Events

Auditors test whether security events are monitored, alerts are configured for anomalous activity, and events are reviewed and investigated. Required evidence includes SIEM configuration, alert rule configurations, and documented security event reviews showing investigation and resolution, not just acknowledgement.

CC7.3: Incident Response

Auditors test whether a documented incident response plan exists, it has been tested, and actual incidents were handled according to the plan. Required evidence includes the IRP document, tabletop exercise records, and incident records for any events during the observation period showing timeline, actions, and post-incident review.

CC8.1: Change Management

Auditors test whether changes to systems and configurations are reviewed and approved before implementation, and there is a separation of duties in the review and deployment process. Required evidence includes change management policy, pull request history showing code review before merge, and deployment pipeline configuration showing an approval gate before production.

CC9.2: Risk Assessment and Third-Party Management

Auditors test whether the organisation assesses risks and manages third-party service providers for security compliance. Required evidence includes annual risk assessment documentation, a vendor inventory with SOC 2 reports or security questionnaire responses on file, and evidence of vendor SOC 2 report review.

A1.1: Availability Monitoring

Auditors test whether availability is monitored, SLAs are defined, and availability incidents are detected and responded to. Required evidence includes uptime statistics for the observation period, monitoring configuration, and incident records for any availability events with documented detection and response times.

Automating SOC 2 Evidence Collection

Manual evidence collection for a twelve-month SOC 2 Type II audit is extremely resource-intensive. Access review records, change management approvals, vulnerability scan results, penetration test reports, vendor SOC 2 reports, background check completion records, security training records, and policy acknowledgements must all be assembled and presented to the auditor. Continuous compliance platforms automate the majority of this work.

• Vanta integrates with AWS, GCP, Azure, GitHub, Slack, Jira, Okta, and over 200 other services via API. It automatically collects evidence for SOC 2, ISO 27001, HIPAA, PCI-DSS, and GDPR, monitors controls continuously, and generates a real-time compliance dashboard. Estimated time savings are 200 to 400 hours per SOC 2 audit cycle.
• Drata offers similar integrations with strong AWS and GitHub support, AI-assisted evidence collection, and a personnel security programme covering background checks, security training, and policy acknowledgements. It supports multi-framework compliance from a single platform.
• Secureframe focuses on automated testing, running automated checks against cloud infrastructure rather than relying on screenshots. It supports annual penetration test scheduling and includes a vendor portal for collecting security assessments.

For organisations preferring not to use a commercial platform, a custom implementation combining AWS Config, Security Hub, CloudTrail, and an S3 evidence archive provides equivalent coverage at lower licensing cost but higher engineering maintenance overhead.

HIPAA Technical Safeguards: Protecting Electronic Protected Health Information

HIPAA's Security Rule applies to any web application that is part of a Covered Entity's systems or is operated by a Business Associate under a BAA. The Technical Safeguards under 45 CFR §164.312 specify the required controls for electronic Protected Health Information. Unlike GDPR (principle-based) and SOC 2 (criteria-based), HIPAA distinguishes between Required Implementation Specifications and Addressable Implementation Specifications. Required means mandatory. Addressable means implement if reasonable and appropriate, or document why an alternative achieves the same objective.

Required and Addressable Controls

Access Control (Required: 164.312(a)(1))

Implement a system that allows only authorised persons to access ePHI. Use role-based access control with explicit authorisation for ePHI access. Prohibit generic shared accounts. Apply minimum necessary access, HIPAA's equivalent of GDPR's data minimization, applied to access decisions. Enforce automatic session timeout after 15 to 30 minutes of inactivity for screens displaying ePHI.

Unique User Identification (Required: 164.312(a)(2)(i))

Every user must have a unique identifier. Shared logins are prohibited. Audit log entries must identify the specific individual who performed each action. A generic service account that performed an action on ePHI does not satisfy this requirement.

Automatic Logoff (Addressable: 164.312(a)(2)(iii))

Implement automatic session timeout for all sessions accessing ePHI. The standard recommendation is 15 minutes of inactivity for clinical workstations and 30 minutes for administrative staff. The timeout must clear the screen or require re-authentication, not merely lock the UI.

Encryption and Decryption (Addressable: 164.312(a)(2)(iv))

Encrypt ePHI at rest using AES-256 or equivalent. Use field-level encryption for ePHI database fields with AWS KMS Customer Managed Keys. Store the encryption key separately from the encrypted data. Document the encryption algorithm, key length, and key management procedure in the Security Policy.

Audit Controls (Required: 164.312(b))

Implement hardware, software, and procedural mechanisms to record and examine all activity in information systems containing or using ePHI. Minimum log content: user identity, action performed, ePHI accessed, timestamp, and success or failure outcome. Retain audit logs for a minimum of six years. Store logs in a tamper-evident system using CloudTrail with log file validation or S3 Object Lock.

Integrity Controls (Addressable: 164.312(c)(1))

Ensure ePHI is not improperly altered or destroyed. Use database integrity constraints. Implement cryptographic checksums on ePHI records, storing the hash of critical fields alongside the record. Maintain a full audit trail for all ePHI modifications, capturing who changed what, when, from what value, and to what value.

Person or Entity Authentication (Required: 164.312(d))

Verify that a person or entity seeking access to ePHI is who they claim to be. MFA is required for all accounts with ePHI access, with TOTP as the minimum and WebAuthn/FIDO2 for administrative accounts. Password policy must require a minimum of 12 characters with complexity requirements, prohibit reuse of the last 12 passwords, and lock accounts after five failed attempts.

Transmission Security (Addressable: 164.312(e)(1))

Use TLS 1.2 or higher for all ePHI transmission over networks. Implement mutual TLS for service-to-service ePHI transmission. Never transmit ePHI in URL parameters, email subjects, or any unencrypted channel. Use a VPN or dedicated connection for bulk ePHI transfers.

AWS BAA and HIPAA-Eligible Services

AWS offers a Business Associate Agreement covering specific HIPAA-eligible services. Before any ePHI is stored in or processed by an AWS service, verify that the service is covered under the AWS BAA. Key HIPAA-eligible AWS services as of 2026 include Amazon EC2, Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon S3, AWS Lambda, Amazon Cognito, Amazon API Gateway, AWS CloudTrail, Amazon CloudWatch, Amazon GuardDuty, Amazon Inspector, AWS Secrets Manager, and AWS KMS.

Storing ePHI in a service not on the HIPAA-eligible list is a HIPAA violation regardless of the encryption status of the data. The AWS BAA is executed via the AWS Artifact console as a click-through agreement before configuring any service to store or process ePHI. The BAA covers AWS's responsibilities under HIPAA. The customer retains responsibility for their own application's security controls under the Shared Responsibility Model.

Best practice is to run HIPAA-covered workloads in a dedicated AWS account with the BAA executed for that account specifically. AWS Control Tower can manage the HIPAA account within the organisation's multi-account structure with HIPAA-specific guardrails applied at the organisational level.

Multi-Framework Compliance: One Implementation, Five Frameworks

The most common and most expensive mistake in enterprise compliance is treating each framework as an independent workstream. Building separate controls for GDPR, then a separate implementation for SOC 2, then separately for PCI-DSS creates three sets of duplicated controls solving the same problems in slightly different ways, three sets of documentation that must all be updated when the underlying system changes, and three separate evidence collections for three different auditors.

The multi-framework approach starts from the opposite direction. Build the single best implementation of each control, documented against all applicable frameworks simultaneously. This is the core principle of secure application architecture for regulated platforms.

The Multi-Framework Control Mapping

Ten technical controls, each implemented once, satisfy all five frameworks simultaneously.

Field-Level Encryption for Sensitive Data

AES-256 encryption with KMS-managed keys satisfies GDPR Article 32(1)(a), PCI-DSS Requirement 3.5.1, SOC 2 CC6.6, HIPAA 164.312(a)(2)(iv), and ISO 27001 A.10.1.1 from a single implementation. The key management procedure is documented once and referenced in all five compliance programmes.

MFA for All Accounts

WebAuthn/FIDO2 for administrative accounts and TOTP for all other users satisfy all five frameworks' authentication requirements. PCI-DSS v4.0 Requirement 8.4.1 specifically requires phishing-resistant MFA for CDE administrators. The same WebAuthn implementation deployed for PCI-DSS compliance also satisfies SOC 2 CC6.1, HIPAA 164.312(d), ISO 27001 A.9.4.2, and GDPR Article 32(1)(b).

Comprehensive Audit Logging

Logs containing who, what, when, where, and outcome, retained for 12 months, satisfy PCI-DSS Requirement 10, SOC 2 CC7.2, GDPR Article 32, and ISO 27001 A.12.4. For HIPAA, retain 12 months online and archive to meet the six-year documentation retention requirement.

Role-Based Access Control with Quarterly Reviews

Quarterly RBAC access reviews satisfy PCI-DSS Requirement 7, SOC 2 CC6.1, HIPAA 164.308(a)(4), and ISO 27001 A.9.2 simultaneously. The review process is documented once, and the evidence is referenced across all four compliance programmes.

TLS 1.2 or Higher with HSTS

TLS enforcement satisfies GDPR Article 32(1)(a), PCI-DSS Requirement 4.2.1, SOC 2 CC6.6, HIPAA 164.312(e)(1), and ISO 27001 A.13.1.1 from a single configuration.

Annual Penetration Testing with SAST/DAST in CI/CD

One annual external penetration test satisfies PCI-DSS Requirement 11.3, SOC 2 CC7.1, ISO 27001 A.12.6, and GDPR Article 32(1)(d). The penetration test report is the single piece of evidence referenced in all four frameworks' audit packages.

Incident Response Plan with Tested Breach Notification

A single tested IRP with documented notification timelines satisfies GDPR Articles 33 to 34, PCI-DSS Requirement 12.10, SOC 2 CC7.3 to CC7.5, HIPAA 164.308(a)(6), and ISO 27001 A.16.1.

Vendor Risk Management

Signed DPAs and BAAs with annual review satisfy GDPR Article 28, HIPAA 164.308(b), PCI-DSS Requirement 12.8, SOC 2 CC9.2, and ISO 27001 A.15.1 from a single vendor management programme.

Data Classification and Inventory

A documented and automated data classification taxonomy satisfies GDPR Article 30, PCI-DSS Requirement 3.2, SOC 2 CC6.1, HIPAA 164.308(a)(1), and ISO 27001 A.8.1 from a single classification framework.

Automated Secrets Management

HashiCorp Vault or AWS Secrets Manager with no hardcoded secrets satisfies GDPR Article 32, PCI-DSS Requirement 6.2.4, SOC 2 CC6.1, HIPAA 164.312(a)(2)(iv), and ISO 27001 A.9.2.4 from a single secrets management implementation.

Policy-as-Code: Encoding Compliance as Automated Enforcement

Policy-as-code is the practice of defining compliance and security policies in machine-executable code that is automatically enforced at every relevant point in the development and deployment lifecycle. A compliance requirement expressed in natural language is enforced only when an auditor checks it. The same requirement, expressed as an AWS Config Rule or a Checkov policy, is enforced at every infrastructure change, automatically, with an immediate consequence.

This is the distinction between secure software development as a periodic activity and as a continuous discipline. Policy-as-code converts compliance from a periodic audit check into a continuous enforcement mechanism.

The Policy-as-Code Toolkit

Five tools, each with a distinct enforcement point, form a complete policy-as-code implementation for secure web application development.

Open Policy Agent (OPA)

OPA uses Rego, a declarative policy language, to evaluate input data and return allow or deny decisions. It is runtime-agnostic and integrates with Kubernetes, API gateways, Terraform, CI/CD pipelines, and microservices. A single OPA policy can enforce RBAC access control for SOC 2 CC6.1 and GDPR data minimisation simultaneously. For example, a Rego rule that allows finance users to access only finance department resources satisfies both SOC 2 CC6.1 and GDPR Article 25 data minimisation in one policy.

OPA is most valuable at three enforcement points: runtime API authorisation validating that every API request satisfies the RBAC policy, Kubernetes admission control validating that pod specifications meet security requirements, and Terraform plan validation checking infrastructure changes against compliance rules before apply.

Checkov

Checkov scans Terraform, CloudFormation, Kubernetes, Dockerfiles, ARM templates, and Ansible configurations for compliance violations using over 750 built-in policies. It runs in the CI/CD pipeline and blocks merges when compliance policies fail. It also runs as a pre-commit hook, giving developers immediate feedback before code reaches the repository.

Relevant built-in checks include CKV_AWS_3 for S3 bucket server-side encryption, CKV_AWS_20 ensuring S3 buckets are not publicly accessible, CKV_AWS_53 checking that API Gateway has WAF enabled, and CKV_AWS_18 verifying CloudTrail log file validation is enabled. Each check maps directly to a compliance requirement, creating a traceable connection between code and compliance obligation.

tfsec and Trivy

tfsec analyses Terraform code for security misconfigurations with deep understanding of Terraform resource relationships. Trivy extends IaC scanning to Kubernetes, CloudFormation, and ARM templates. Both generate SARIF output for CI integration and provide inline annotations showing exactly which line contains a misconfiguration and which compliance rule it violates. Common findings include unrestricted ingress on security groups, unencrypted EBS volumes, unencrypted RDS instances, and IAM policies with wildcard permissions.

AWS Config Rules

AWS Config evaluates AWS resource configurations against defined compliance rules on a continuous basis. Every resource configuration change triggers a compliance evaluation. Non-compliant resources are flagged in the AWS Config compliance dashboard. Auto-remediation Lambda functions can fix specific non-compliant configurations automatically, such as re-enabling S3 encryption or closing exposed security group rules without human intervention.

Managed rules relevant to compliance programmes include encrypted volumes for EBS encryption, s3-bucket-public-read-prohibited, mfa-enabled-for-iam-console-access, iam-no-root-access-key, cloudtrail-enabled, and vpc-sg-open-only-to-authorized-ports. Each rule maps to specific requirements across PCI-DSS, HIPAA, SOC 2, and ISO 27001.

HashiCorp Sentinel and AWS Service Control Policies

Sentinel integrates directly with Terraform Cloud and Enterprise, running policies after Terraform plan and before Terraform apply. Hard-mandatory policies cannot be bypassed even by administrators. An example policy requiring all KMS keys to have key rotation enabled enforces PCI-DSS Requirement 3.6, HIPAA 164.312(a)(2)(iv), and ISO 27001 A.10.1 at the infrastructure-as-code layer before any deployment occurs.

AWS Service Control Policies operate at the AWS Organizations level and restrict what any account in the organisation can do, regardless of its IAM policies. They cannot be overridden by account-level IAM policies or even by the root account. SCPs that deny disabling CloudTrail, deny creation of unencrypted S3 buckets, and deny unencrypted RDS instance creation enforce PCI-DSS Requirement 10, Requirement 3, and SOC 2 CC6.6 at the highest possible enforcement level.

Data Residency and Data Sovereignty Architecture

Data residency is one of the most architecturally constraining compliance requirements for web applications. Some jurisdictions mandate that data be physically stored within the jurisdiction. Others restrict transfers of personal data to countries without adequate data protection levels. Understanding the requirements by jurisdiction before designing the data architecture avoids costly infrastructure redesigns later.

Data Residency Requirements by Jurisdiction

EU and UK Under GDPR

GDPR and UK GDPR do not mandate EU or UK data residency. Personal data may be transferred outside the EU and UK only to countries with an adequacy decision, or using an appropriate transfer mechanism such as Standard Contractual Clauses. For EU and UK personal data where clients contractually require data residency, choose AWS regions in the EU, including eu-west-1 in Ireland, eu-central-1 in Frankfurt, or eu-west-2 in London.

India Under the DPDP Act 2023

The DPDP Act does not currently mandate data localisation for all personal data, but the Central Government may restrict transfers to certain countries by notification. Using the Indian AWS region at ap-south-1 in Mumbai for India user data reduces cross-border transfer risk. Organisations should monitor MeitY notifications as the DPDP Act implementing rules are finalised, as significant data fiduciaries may face additional obligations.

Russia Under Federal Law 242-FZ

Russia mandates data localisation. Personal data of Russian citizens must be stored in databases located in Russia. The initial collection, recording, systematisation, and accumulation of personal data of Russian citizens must occur in Russia. AWS and Google do not have Russian regions. Russian cloud providers, including Yandex Cloud, SberCloud, and Mail.ru Cloud, provide compliant infrastructure.

China Under PIPL and DSL

China's Personal Information Protection Law and Data Security Law require that personal information and important data collected in China be stored in China. Cross-border transfers require a CAC security assessment for certain transfer types, standard contract clauses for smaller transfers, or personal information protection certification. Mandatory use of Chinese cloud providers, including Alibaba Cloud, Tencent Cloud, or Huawei Cloud, is required. The AWS China region is operated by Sinnet, a separate entity from AWS global. An ICP licence is required for internet services in China.

US Under HIPAA and FedRAMP

There is no general US data residency law. HIPAA does not mandate US-only storage for PHI, but requires that all locations be covered by the BAA. FedRAMP requires US-based data processing for federal government data, using AWS GovCloud exclusively.

EU Standard Contractual Clauses: Technical Compliance Measures

The EU Standard Contractual Clauses (2021 edition, applicable to all new contracts since September 2021) require that data exporters and importers document specific technical measures in Annex II of the SCC agreement. Generic descriptions of industry-standard security are not sufficient. Annex II must describe the actual technical controls implemented.

Required documentation includes the encryption method and key length, specifically AES-256-GCM at rest and TLS 1.3 in transit, pseudonymisation techniques applied before transfer where relevant, access controls in the destination country, including IAM roles, MFA, and RBAC, audit logging capability, incident response and breach detection, and physical security certifications for the destination infrastructure.

For transfers to the US and other countries without an EU adequacy decision, a Transfer Impact Assessment is also required. The TIA assesses the legal and technical risks of the transfer, specifically the risk of surveillance law access to the transferred data. It documents the laws of the destination country, whether they provide equivalent protection to EU law, what technical measures reduce the risk of government access, and the likelihood of government requests. The TIA is a standard component of SCC compliance that supervisory authorities expect to see.

Audit Readiness: From Continuous Compliance to the Annual Audit

A compliance audit is fundamentally a documentation exercise. The organisation must demonstrate that the required controls exist, that they are designed correctly, and, for Type II audits like SOC 2 Type II, that they operate continuously and effectively throughout the entire observation period.

Organisations that approach the audit as a last-minute evidence gathering exercise discover compliance gaps under time pressure and often receive qualifications in the auditor's report. Organisations that treat compliance as a continuous operational discipline approach every audit with confidence. The evidence is already collected, the controls are already documented, and the audit is a verification exercise rather than a remediation scramble.

The Audit Evidence Package

Each framework requires specific evidence categories. Understanding what auditors need before the audit begins allows organisations to collect evidence continuously rather than reactively.

Evidence Category	GDPR	PCI-DSS	SOC 2	HIPAA	ISO 27001
Policy Documentation	Privacy Policy, ROPA, DPIA	Written security policy, all referenced policies	Security, Availability, and TSC policies	HIPAA-specific policies, sanctions, and workforce training	ISMS scope, InfoSec Policy, SoA
Access Control Evidence	Basis for each user's access	Access list with justification, quarterly review records	Quarterly access review sign-offs, JML process records	Access authorisation records, minimum necessary evidence	Access rights review, provisioning records
Encryption Evidence	Encryption for PII in transit and at rest	Key management docs, key custodians, rotation schedule	TLS and at-rest encryption configuration	Encryption implementation documentation	Encryption policy, key management procedure
Vulnerability Management	Regular testing per Art. 32(1)(d)	SAST/DAST results, penetration test, and patching evidence	Vulnerability scans, pentest report, and patch records	Risk analysis, vulnerability assessment results	Vulnerability records, pentest reports, patch records
Third-Party Management	DPAs signed, transfer mechanisms, due diligence	Vendor SOC 2/PCI reports or questionnaires	Vendor SOC 2 reports, annual review records	BAAs signed, BA due diligence records	Supplier assessment records, annual review

Compliance Programme Governance

Maintaining compliance between audits requires a structured governance calendar. The following quarterly cadence keeps a growing platform continuously audit-ready.

Q1 Activities (January to March)

• Conduct Q4 access review and remove unnecessary access
• Document manager approvals and submit to auditor evidence queue
• Schedule annual penetration test for Q2
• Launch annual security awareness training and track completion to 100%
• Rotate KMS CMKs and Vault keys per schedule
• Collect updated SOC 2 reports and ISO certificates from vendors

Q2 Activities (April to June)

• Execute Q1 access review
• Run annual penetration test and track remediation to closure
• Conduct annual risk assessment and update risk register
• Identify new risks and present findings to CISO or CTO
• Review all security and privacy policies for regulatory changes

Q3 Activities (July to September)

• Conduct Q2 access review
• Run mid-year compliance dashboard review in Vanta, Drata, or Secureframe
• Identify and remediate failing controls before audit season
• Execute disaster recovery test and document RTO and RPO results
• Update Records of Processing Activities for new data flows and processors

Q4 Activities (October to December)

• Conduct Q3 access review
• Assemble evidence package and conduct audit readiness review
• Run gap assessment against audit scope with GRC lead and legal counsel
• Execute annual incident response tabletop exercise
• Review consent management records and verify consent refresh
• Confirm opt-out mechanisms are functional
• Run automated data retention policy check and verify deletions

Compliance Is Infrastructure: Build It Once, Maintain It Continuously

Organisations that treat web application compliance as a periodic event spend more on it than those that treat it as infrastructure. Infrastructure-grade compliance means controls exist before data arrives, evidence is collected automatically, and the gap between actual security and documented compliance is measured in minutes, not months.

A unified secure application architecture with one set of controls mapped to GDPR, PCI-DSS, SOC 2, HIPAA, and ISO 27001 simultaneously is simpler than building separate compliance implementations for each framework. It avoids redundancy, inconsistency, and maintenance overhead.

Secure web application development that accounts for regulatory requirements from the first architecture decision costs significantly less over time than retrofitting compliance after launch. Audits become documentation exercises. Penetration test results confirm what your CI/CD pipeline already enforces. Access reviews confirm what automated systems already maintain.

This approach reduces actual compliance failure risk, data breach exposure, regulatory fines, and lost enterprise customers. The goal is not to pass audits, but to genuinely satisfy the security and regulatory requirements that protect users, customers, and your business.

If you are building or modernising an enterprise platform and need web application security built in rather than bolted on, Mobisoft designs and implements compliance ready web applications for healthcare, financial services, SaaS, and regulated industries. Contact us to discuss your compliance architecture needs.