ACME Customer Platform

Customer PII (name, email, phone, billing address) via web registration form. Payment card details entered directly into Stripe Elements iframe — never touches our servers. Support tickets via authenticated web form with optional file attachment (max 10MB). SSO tokens from Google/Microsoft OAuth for enterprise customers.

Registration form accepts free-text fields — injection risk on name and address fields. Email validation is client-side only, no server-side verification of deliverability. File attachments on support tickets could contain malware. OAuth state parameter must be validated to prevent CSRF. No rate limiting on registration endpoint — enumeration and bot abuse risk.

Server-side input validation with strict allowlists on all PII fields. Email verification link required before account activation. File attachments scanned by ClamAV before storage. OAuth state validated server-side with PKCE. Registration endpoint rate-limited to 5 attempts per IP per hour. All collection events logged with timestamp and source IP.

Input validation tested with OWASP testing guide payloads. Registration rate limiting confirmed under load test. However, we have not tested the ClamAV integration with polymorphic samples — only EICAR test file. The OAuth PKCE flow has been reviewed but not pen-tested independently. Residual risk: sophisticated file-based attacks may bypass scanning.

Browser to platform: TLS 1.3 terminated at load balancer. Platform to PostgreSQL: TLS within VPC. Platform to Stripe: TLS 1.2+ to Stripe API endpoints. Platform to email provider: TLS to SendGrid API. Internal service mesh uses mTLS between microservices.

Load balancer terminates TLS — traffic within the VPC is encrypted but the load balancer has access to plaintext. SendGrid API key transmitted in HTTP headers — if intercepted at the provider side, email sending could be hijacked. No certificate pinning on mobile app — susceptible to corporate proxy interception.

VPC peering with no public internet exposure for database traffic. Stripe API keys rotated quarterly and stored in AWS Secrets Manager. SendGrid API key scoped to send-only permissions. Mobile app uses public key pinning with backup keys. All inter-service traffic logged at the mesh level.

Network architecture reviewed by external consultant in January 2026. Certificate pinning tested on both iOS and Android builds. However, the mTLS certificate rotation is manual — automated rotation not yet implemented. This is a known operational risk.

Billing calculation: usage metering aggregated hourly, invoiced monthly via Stripe. Customer segmentation: automated tier assignment based on usage thresholds (no human profiling). Support ticket routing: keyword-based assignment to team queues. Account deactivation: automated after 90 days of non-payment with 3 warning emails. All processing performed by the platform team in London. No offshore processing. No automated individual decision-making under Art 22.

Billing calculation errors could result in overcharging — financial and reputational impact. Tier assignment logic is opaque to customers — could be perceived as unfair even though it is rule-based. Support ticket routing by keyword could misroute sensitive security reports to general support. Account deactivation automation has no human review step — a payment processing failure at Stripe could cascade into mass deactivations.

Billing calculations reconciled daily against Stripe's records with alerts on discrepancy. Tier assignment rules published in customer documentation. Security-related support tickets tagged separately with dedicated routing. Account deactivation requires 3 failed payment attempts AND manual approval for accounts above a revenue threshold. All processing actions logged with actor attribution.

Billing reconciliation has caught 2 discrepancies in the last quarter, both resolved within 24 hours. Tier assignment reviewed quarterly. However, the mass-deactivation scenario has not been tested — we have no chaos engineering practice for payment processor failures. This is a gap.

PostgreSQL 16 on AWS RDS (eu-west-2). Encrypted at rest with customer-managed KMS key. Redis for session cache (4-hour TTL, encrypted in transit). S3 for support ticket attachments (SSE-S3 encryption, bucket policy denies public access). Daily automated backups retained for 30 days in the same region. No cross-region replication.

RDS snapshots inherit the KMS key — if the key is compromised, all snapshots are exposed. Redis has no at-rest encryption — session data is plaintext in memory. S3 bucket policy could be misconfigured by a team member with IAM write access. Backup retention of 30 days means deleted customer data persists in backups for up to 30 days after deletion request.

KMS key policy restricted to 2 IAM roles with MFA required for key management actions. Redis configured with AUTH and TLS. S3 bucket policy version-controlled and changes require PR review. Deletion requests logged and reconciled against backup retention schedule — customers informed of the 30-day backup window in privacy notice.

KMS key access audited quarterly via CloudTrail. S3 bucket policy reviewed monthly. Redis AUTH tested in staging. However, we have not tested the scenario where a KMS key is rotated — we do not know if old snapshots remain decryptable. This needs investigation.

Stripe (processor): payment card data, billing address, invoice amounts. SendGrid (processor): customer email addresses, notification content. AWS (sub-processor): all data at rest and in transit within their infrastructure. Google Analytics: anonymised usage data only (IP anonymisation enabled). No international transfers — all processors confirmed EU/UK data residency.

Stripe has access to billing data that could be correlated with transaction patterns. SendGrid processes email addresses — a breach at SendGrid would expose our entire customer email list. AWS has theoretical access to all data as the infrastructure provider. Google Analytics anonymisation could be reversed with sufficient auxiliary data.

DPAs in place with Stripe, SendGrid, and AWS. Stripe PCI DSS Level 1 certified — we rely on their attestation. SendGrid access scoped to send-only — no access to stored email lists. AWS shared responsibility model documented. Google Analytics replaced with privacy-respecting alternative on the roadmap for Q3 2026.

DPAs reviewed by external counsel in March 2026. Stripe and AWS certifications verified. SendGrid's security posture reviewed via their SOC 2 Type II report. However, we have not exercised our audit rights with any processor. The Google Analytics replacement is not yet implemented.

Active customer data: retained for duration of contract plus 12 months. Billing records: 7 years (HMRC requirement). Support tickets: 3 years from resolution. Audit logs: indefinite. Account data after deletion request: purged from primary stores within 30 days, from backups within 30 days of next backup cycle. Marketing consent records: retained indefinitely as evidence of lawful basis.

The 12-month post-contract retention is generous — the original justification was 'in case they come back' which is not a valid lawful basis. Support tickets retained for 3 years may contain sensitive information shared during troubleshooting. Audit log indefinite retention means the dataset grows without bound — no archival strategy.

Retention schedule documented and published in the privacy notice. Automated purge jobs run weekly for expired data. Post-contract retention reduced from 12 months to 3 months (change pending legal sign-off). Support tickets reviewed at 12 months and sensitive content redacted. Audit log archival to cold storage after 2 years — implemented but not yet tested under load.

Automated purge verified monthly with reconciliation reports. Retention schedule reviewed quarterly against stated purposes. However, the 12-to-3-month reduction has not yet been approved by legal and is therefore not in effect. The audit log archival has not been tested with a realistic data volume.

Account deletion: soft-delete in application, hard-delete from PostgreSQL after 30-day grace period. S3 objects: lifecycle policy deletes after retention period. RDS snapshots: automatic expiry after 30 days. Redis: TTL-based expiry, no manual intervention needed. Physical media disposal: managed by AWS under their shared responsibility model — we do not handle physical media.

Soft-delete grace period means data is recoverable for 30 days — a determined insider could access 'deleted' accounts. RDS snapshots retain data beyond the application-level deletion. Search indices and caches may retain references to deleted data. Third-party processors (Stripe, SendGrid) may retain data beyond our deletion request.

Soft-delete access restricted to 2 admin roles with MFA. Deletion cascade includes search index purge and cache invalidation. Stripe and SendGrid deletion requests issued via API at time of account deletion with confirmation logged. Quarterly audit of soft-deleted accounts to verify hard-delete completion.

Deletion cascade tested end-to-end in staging including search index and cache. Stripe/SendGrid deletion confirmation verified. However, we have not verified that AWS actually destroys the physical media underlying decommissioned EBS volumes. We rely on their attestation. Residual risk accepted.