All 68 controls¶
Every control on the auditor's checklist, with how Soon meets it and the evidence to capture. Grouped by Common Criteria series.
Generated from the checklist · last built 2026-08-23.
CC1 — Control Environment¶
12 controls: 🟡 In progress 8 · ➖ N/A 3 · ✅ Done 1
1. Code of conduct & disciplinary policy¶
CC1.1 · 🟡 In progress
Code of Conduct/disciplinary rules are covered by the HR Security Policy (ISMS-DOC-A05-1-2, absorbed the Disciplinary Process) in the ISMS repo (SoonHQ/isms). Status: draft — needs owner approval and signed acknowledgements from all 4 founders + Andrea. Owner: Olaf.
Evidence to capture
Copy of the policy (including the disciplinary section) plus copies of signed acknowledgments from every employee and contractor.
2. Confidentiality agreements (NDAs)¶
CC1.1 · 🟡 In progress
NDA template + Schedule of Confidentiality Agreements exist (ISMS-DOC-A06-6-1/6-2). NEEDS INPUT: Need to confirm signed NDAs are on file for all founders and the external consultant (Andrea/CyberSquad). Owner: Olaf.
Evidence to capture
Copies of signed NDAs from every employee and contractor (redact personal details).
3. Employment agreements¶
CC1.1 · 🟡 In progress
Guidelines for Inclusion in Employment Contracts (ISMS-DOC-A06-2-1) define confidentiality + security responsibilities. NEEDS INPUT: Employment construct per founder (employee vs DGA vs ZZP) is still open (OPEN-QUESTIONS Q3) — signed agreements need collecting. Owner: Olaf.
Evidence to capture
Copies of signed employment agreements for every employee (redact personal details).
4. Contractor agreements¶
CC1.1 · 🟡 In progress
Contractor terms covered by the same employment-contract guidelines + NDA. Applies mainly to Andrea Cardinali (CyberSquad, external consultant). NEEDS INPUT: Confirm a signed contractor agreement/DPA is on file. Owner: Olaf.
Evidence to capture
Copies of signed contractor agreements for every contractor (redact personal details).
5. Board / leadership oversight of security¶
CC1.2 · 🟡 In progress
Security is a standing item at the weekly ISMS meeting (Thursdays 13:00 CEST); minutes are kept in the repo (docs/09-performance/meeting-log/). Management Review procedure ISMS-DOC-09-4 defines the annual leadership review. Evidence: meeting-log entries. Owner: Olaf.
Evidence to capture
Screenshot of meeting minutes or the memo showing the date and attendees.
6. Board charter¶
CC1.2 · ➖ N/A
Soon Technologies B.V. is founder-run with no separate board of directors; the 4 founders are the leadership body. Oversight is evidenced by the weekly ISMS meeting minutes and the Executive Support Letter (ISMS-DOC-05-3) instead of a board charter.
Evidence to capture
Screenshot of the adopted board charter with date.
7. Board expertise documented¶
CC1.2 · ➖ N/A
No separate board — see #6. Leadership expertise is documented via the founders' roles in the Roles & Responsibilities doc (ISMS-DOC-05-2).
Evidence to capture
Screenshot of board bios or LinkedIn profiles saved in your evidence folder.
8. Org chart & defined reporting lines¶
CC1.3 · 🟡 In progress
Roles, Responsibilities and Authorities (ISMS-DOC-05-2) names the security owner (Olaf Jacobson, ISM) and control owners (Thomas — platform/access; Melvin — infra/backups). NEEDS INPUT: A simple org chart image still needs to be produced as the screenshot evidence. Owner: Olaf.
Evidence to capture
Screenshot of the current org chart with the security owner labeled.
9. Assign a security owner¶
CC1.3 · ✅ Done
Olaf Jacobson is the named Information Security Manager, documented in Roles & Responsibilities (ISMS-DOC-05-2) and throughout the ISMS. Evidence: ISMS-DOC-05-2 + AGENTS.md. Owner: Olaf.
Evidence to capture
Screenshot of the signed memo or job description.
10. Job descriptions & competence¶
CC1.4 · 🟡 In progress
Security responsibilities per role are in ISMS-DOC-05-2 and the Competence, Awareness & Training procedure (ISMS-DOC-07-1). NEEDS INPUT: Formal per-role job descriptions are not written for a 4-founder team — confirm whether to produce them. Owner: Olaf.
Evidence to capture
Screenshot of a job description showing security responsibilities.
11. Background checks¶
CC1.4 · 🟡 In progress
Employee Screening Procedure + checklist exist (ISMS-DOC-A06-1-1 / ISMS-FORM-A06-1-1). Confirmed 2026-08-08: Soon WILL run background checks for future hires. No hires since the ISMS started, so there is no completed check to evidence yet; the control is the documented procedure plus the first completed check on the next hire. NL-appropriate scope: VOG (Certificate of Conduct) + identity/right-to-work + reference and employment-history verification. Owner: Olaf.
Evidence to capture
Screenshot of a completed background check confirmation (redacted).
12. Performance reviews & accountability¶
CC1.5 · ➖ N/A
Not applicable for now: Soon is 4 founders with no employer/employee performance-review structure. Accountability runs through the weekly ISMS meeting and the roles in ISMS-DOC-05-2. Confirmed by Olaf 2026-08-08 — to be introduced when the company hires beyond the founding team. Owner: Olaf.
Evidence to capture
Screenshot of the review template and evidence one was completed (redacted).
CC2 — Communication¶
11 controls: 🟡 In progress 2 · ✅ Done 8 · ➖ N/A 1
13. Information Security Policy¶
CC2.1 · 🟡 In progress
Information Security Policy (ISMS-DOC-05-4) exists in the ISMS repo, rewritten Soon-specific. Status: draft — needs formal owner approval (approved_by/approved_date) to be audit-ready. Evidence: the approved policy showing version + approval date. Owner: Olaf.
Evidence to capture
Copy of the approved policy showing title, version, and approval date.
14. Security awareness training¶
CC2.2 · 🟡 In progress
Security training material is ESSENTIALS.md, delivered via the /isms:onboard command; completions are logged in the Security Training & Awareness Log (ISMS-DOC-07-5) on a quarterly refresher cadence. NEEDS INPUT: The log currently has no entries — all 4 founders + Andrea need to complete a round. Owner: Olaf.
Evidence to capture
Screenshot of the training material and a completion log with names and dates.
15. Policies shared with all staff¶
CC2.2 · ✅ Done
All policies live in one place — the private GitHub repo SoonHQ/isms — readable by the whole team, plus a browsable MkDocs site (Soon Security Handbook). Access is documented in the Control of Documented Information procedure (ISMS-DOC-07-3). Evidence: repo + site screenshot. Owner: Olaf.
Evidence to capture
Screenshot of the shared policy folder and the announcement message.
16. Whistleblower policy & anonymous channel¶
CC2.2 · ➖ N/A
Not applicable at current size, with a defined trigger to revisit. Soon is 4 founders plus one external consultant; an anonymous channel cannot be meaningfully anonymous in a group that small, and every reporting route already reaches the ISM directly. Concerns are raised via Slack #Security or security@soon.works, and (because the ISM is a founder) may be raised to any other founder. Whistleblowing protections are documented in the HR Security Policy. Trigger to implement a true anonymous channel: headcount reaching ~10, or the first non-founder employee (also the point the EU Whistleblower Directive threshold of 50 becomes relevant to plan for). Confirmed by Olaf 2026-08-08. Owner: Olaf.
Evidence to capture
Copy of the policy plus a screenshot of the live anonymous reporting form.
17. System changes communicated to staff¶
CC2.2 · ✅ Done
System/product changes are communicated to the team via Slack (#Development / #DevOps / #General) and tracked in Linear + GitHub PRs. The Change Management Process (ISMS-DOC-A08-32-1) documents this. Evidence: Slack announcement + PR/release history. Owner: Thomas.
Evidence to capture
Screenshot of a recent internal release note or changelog message.
18. Customer-facing security commitments¶
CC2.3 · ✅ Done
Security commitments to customers are published at https://soon.works/legal/terms, https://soon.works/legal/privacy and https://soon.works/legal/gdpr, and summarised in the customer-facing Security Overview. NEEDS INPUT: the Security Overview still claims blanket 'MFA enforced' and 'hosted entirely on AWS' — correct it to the confirmed tiered-MFA position and the real infrastructure before circulating. Owner: Olaf.
Evidence to capture
Screenshot of the live privacy policy page with the URL visible.
19. Master Service Agreement (MSA)¶
CC2.3 · ✅ Done
Self-serve / non-enterprise customers accept Soon's standard terms published at https://soon.works/legal/terms, with the privacy notice at https://soon.works/legal/privacy and the GDPR/DPA terms at https://soon.works/legal/gdpr — these carry the confidentiality, data-protection and security commitments. Enterprise customers sign a negotiated agreement; signed PDFs are held in Google Drive. Confirmed by Olaf 2026-08-08. Evidence: the three public legal pages + a sample signed enterprise agreement (redacted). Owner: Olaf.
Evidence to capture
Screenshot of the MSA template showing the security commitments section.
20. System Description¶
CC2.3 · ✅ Done
System Description written: ISMS-DOC-04-2 (docs/04-context/ISMS-DOC-04-2-system-description.md) — service and boundaries, in/out of scope components, data processed, infrastructure verified against the live AWS account (2026-08-08), sub-processors, control environment, known limitations under remediation, and complementary user entity controls. Owner: Olaf.
Evidence to capture
Screenshot of the approved system description document with date.
21. Channel for reporting security concerns¶
CC2.3 · ✅ Done
Security concerns are reported via the Slack #Security channel (always @-mentioning) with security@soon.works as the email paper trail, per the Information Security Event Reporting Procedure (ISMS-DOC-A06-8-1). Evidence: procedure + channel screenshot. Owner: Olaf.
Evidence to capture
Screenshot of the security contact published on your website.
22. Customer support channel¶
CC2.3 · ✅ Done
Customer support runs through Intercom (in-product messenger + email), staffed by the team. Evidence: Intercom workspace screenshot. Note: Intercom is currently US-hosted — EU migration tracked as Linear S-303. Owner: Olaf.
Evidence to capture
Screenshot of the live support page or support email address on your site.
23. Customers notified of critical changes¶
CC2.3 · ✅ Done
Customers are notified of critical changes and incidents by email, plus the public status page at https://status.soon.works/ for availability and incident updates. Timelines and responsibilities are defined in the Incident Response Procedure (ISMS-DOC-A05-26-1) and, for personal-data breaches, the GDPR 72-hour Personal Data Breach Notification Procedure (ISMS-DOC-A05-34-2). Confirmed by Olaf 2026-08-08. Evidence: status page screenshot + a sample customer notification email. Owner: Olaf.
Evidence to capture
Screenshot of a recent customer update email or changelog post.
CC3 — Risk Assessment¶
4 controls: 🟡 In progress 2 · ✅ Done 2
24. Defined business & security objectives¶
CC3.1 · 🟡 In progress
Information Security Objectives and Plan (ISMS-DOC-06-1) defines the security objectives; measurement is defined in Monitoring, Measurement, Analysis and Evaluation (ISMS-DOC-09-1). Status: draft — needs approval and a first measurement cycle. Owner: Olaf.
Evidence to capture
Screenshot of the documented objectives with an approval date.
25. Annual risk assessment¶
CC3.2 · 🟡 In progress
Risk Assessment and Treatment Process (ISMS-DOC-06-2) + Risk Assessment Report (ISMS-DOC-06-3, ~22 risks incl. R-22 product MFA gap) exist and are Soon-specific, driven by the Information Asset Inventory. Status: draft — needs owner approval; annual cadence to be evidenced. Owner: Olaf.
Evidence to capture
Screenshot of the completed, dated risk assessment.
26. Fraud risk considered¶
CC3.3 · ✅ Done
Fraud risk is now explicitly assessed in the Risk Assessment Report (ISMS-DOC-06-3 v0.4, added 2026-08-08) with a dedicated 'Fraud risk (SOC 2 CC3.3)' section covering fraud AGAINST Soon (R-24 insider misuse of privileged access, R-25 Stripe billing manipulation, R-28 invoice/CEO fraud), fraud USING Soon's systems (R-27 admin account takeover), and fraud THROUGH the product (R-26 a customer's staff manipulating hours/schedules for pay). The section also records the inherent segregation-of-duties limitation at four founders and the detective compensating controls (tamper-evident CloudTrail/GuardDuty logging, quarterly access reviews, peer-reviewed changes). Owner: Olaf.
Evidence to capture
Screenshot of the fraud risk section of your risk assessment.
27. Assess impact of major changes¶
CC3.4 · ✅ Done
Impact of major changes is assessed through the Change Management Process (ISMS-DOC-A08-32-1) — PR review + CI/CD gates — and significant changes trigger a risk review per ISMS-DOC-06-2. Evidence: PR history showing review of a significant change. Owner: Thomas.
Evidence to capture
Screenshot of a completed change risk questionnaire.
CC4 — Monitoring¶
2 controls: 🟡 In progress 2
28. Periodic control self-assessment¶
CC4.1 · 🟡 In progress
Control self-assessment is defined by the Procedure for Internal Audits (ISMS-DOC-09-2) — performed independently by Andrea (CyberSquad) — plus the new Continuous Control Monitoring system (ISMS-DOC-09-6) which checks controls automatically. NEEDS INPUT: First internal audit not yet run. Owner: Olaf/Andrea.
Evidence to capture
Screenshot of the completed self-assessment with date and reviewer.
29. Track and remediate deficiencies¶
CC4.2 · 🟡 In progress
Deficiencies are tracked via the Nonconformity & Corrective Action procedure (ISMS-DOC-10-1) with actions in Linear. The GRC dashboard (soon-grc) surfaces failing controls and alerts #Security. NEEDS INPUT: CAPA log has no entries yet. Owner: Olaf.
Evidence to capture
Screenshot of the issue log showing at least the column headers and status.
CC5 — Control Activities¶
3 controls: ✅ Done 2 · 🟡 In progress 1
30. Controls mapped to risks¶
CC5.1 · ✅ Done
Controls are mapped to risks in the Statement of Applicability (ISMS-FORM-06-2 — all 93 Annex A controls with applicability + justification) and the Risk Treatment Plan (ISMS-DOC-06-4). Evidence: SoA. Owner: Olaf.
Evidence to capture
Screenshot of the risk register showing a controls column.
31. Technology controls selected¶
CC5.2 · ✅ Done
Technology controls are selected and documented across the Annex A.8 policy set (access control, cryptography, logging, backup, network/cloud security, secure development) and implemented on AWS/GitHub. Evidence: SoA + the A.8 policies. Owner: Thomas.
Evidence to capture
Screenshot of the technical controls summary document.
32. Policies enacted through procedures¶
CC5.3 · 🟡 In progress
Policies are enacted through concrete procedures (access management JML, incident response, change management, evidence collection) and increasingly automated via soon-grc continuous control monitoring. Most procedures are status:draft pending approval. Owner: Olaf.
Evidence to capture
Copy of a policy showing responsibilities and review frequency.
CC6 — Access¶
18 controls: 🟡 In progress 12 · ✅ Done 6
33. Access control policy & least privilege¶
CC6.1 · 🟡 In progress
Access Control Policy (ISMS-DOC-A05-15-1, owner Thomas) covers least privilege + RBAC, and the User Access Management Process (ISMS-DOC-A05-18-1) covers joiner/mover/leaver. Status: draft — needs approval. Automated check CHK-ACC-GH-01 collects access lists. Owner: Thomas.
Evidence to capture
Copy of the approved policy plus the access matrix.
34. MFA on all critical systems¶
CC6.1 · 🟡 In progress
MFA is risk-tiered (confirmed 2026-07-03): REQUIRED on sensitive systems (AWS, GitHub); lower-value tools use Google login (inherits Google's protections); unimportant tools password-only. Automated checks CHK-MFA-01 (AWS IAM) and CHK-MFA-GW-01 (Workspace 2SV) verify this. NEEDS INPUT: Note for the auditor: the PRODUCT has no native MFA for email/password customer accounts (gap R-22) — SSO/social login offered instead. Owner: Thomas.
Evidence to capture
Screenshot of MFA enforcement settings in each critical system.
35. Password manager & password policy¶
CC6.1 · ✅ Done
Enpass is the company password manager (confirmed 2026-08-08), used to store and generate credentials; password requirements (length/complexity/uniqueness, no reuse) are defined in the Access Control Policy (ISMS-DOC-A05-15-1). Evidence to capture: screenshot of the Enpass vault/team setup and the password section of the policy. Owner: Olaf.
Evidence to capture
Screenshot of the password manager admin console showing active users.
36. Data classification policy¶
CC6.1 · 🟡 In progress
Classification scheme (Public/Internal/Confidential/Restricted) is applied to every ISMS document via front-matter and defined in the Control of Documented Information procedure (ISMS-DOC-07-3) + Data Handling & Deletion Policy. NEEDS INPUT: A standalone Information Classification Procedure (ISMS-DOC-A05-12-1) is still to be written. Owner: Olaf.
Evidence to capture
Copy of the approved data classification policy.
37. Production asset inventory¶
CC6.1 · ✅ Done
Information Asset Inventory (ISMS-DOC-A05-9-2) lists production assets: AWS eu-west-1 (Fargate/ECS/ECR/Lambda/S3/SES/CloudWatch), RDS MySQL (rds-soon-soon-prd, rds-knab-soon-prd), Netlify frontend, Redis, plus all SaaS sub-processors. Reviewed quarterly. Evidence: the inventory. Owner: Olaf.
Evidence to capture
Screenshot of the asset inventory list with an updated date.
38. Access provisioning on hire¶
CC6.2 · 🟡 In progress
Provisioning on hire is defined in the User Access Management Process (ISMS-DOC-A05-18-1) — access granted by role, approved by the ISM. NEEDS INPUT: No new joiners since the ISMS started, so no completed record exists yet to screenshot. Owner: Thomas.
Evidence to capture
Screenshot of a completed onboarding checklist for a recent hire.
39. Access removal on departure & quarterly review¶
CC6.3 · 🟡 In progress
Removal on departure is defined in ISMS-DOC-A05-18-1 + the Termination & Change of Employment Checklist (ISMS-FORM-A06-5-1); quarterly access reviews are scheduled in the Evidence Register (AWS IAM, GitHub, WorkOS, Google Workspace) and automated via CHK-ACC-GH-01/CHK-ACC-GW-01. NEEDS INPUT: First quarterly review not yet performed. Owner: Thomas.
Evidence to capture
Screenshot of a completed offboarding checklist and the latest access review.
40. Physical access / office & devices¶
CC6.4 · 🟡 In progress
Perimeter protection is AWS-native (VPC, security groups, TLS-terminating load balancers, Cloudflare in front of web properties) and account-level S3 Block Public Access was enabled 2026-08-08. NEEDS INPUT: the production database endpoint is currently publicly reachable (security group permits 0.0.0.0/0 and ::/0 on 3306) — remediation is planned this week under Linear S-299 (move to private subnets, disable public access, put the dsync Lambda in-VPC). Detected automatically by the soon-grc collector (CHK-NET-01/CHK-PUB-01). Owner: Thomas.
Evidence to capture
Copy of the physical security section, or the badge/key holder list.
41. Secure disposal of data & devices¶
CC6.5 · 🟡 In progress
Network segregation: development is already private; the production database is being moved into private subnets with no public endpoint under Linear S-299 — the exact runbook (incl. the IPv6 rule and the dsync Lambda VpcConfig blocker) is documented in ISMS-DOC-A05-37-1 §3, scheduled for the week of 2026-08-10. Engineers will reach the database via SSM Session Manager port forwarding (logged in CloudTrail), documented in §2. A current network diagram is still to be produced. Owner: Thomas.
Evidence to capture
Screenshot of the disposal procedure and one wipe confirmation if available.
42. Data retention & disposal procedures¶
CC6.5 · 🟡 In progress
Retention confirmed by Olaf 2026-08-08: customer data is retained for 90 DAYS after contract end, then deleted. This is being written into the Records Retention & Protection Policy (ISMS-DOC-A05-33-1) and the Data Handling & Deletion Policy, and sets the S3 evidence-store Object Lock retention baseline. Backups age out on their own retention cycle (7d/30d). Owner: Olaf.
Evidence to capture
Copy of the approved retention policy showing the retention schedule.
43. Customer data deletion on departure¶
CC6.5 · 🟡 In progress
Customer data is deleted 90 days after contract end (confirmed 2026-08-08), covering both the application database and any exports; backups then age out on their normal 7d/30d cycle. Governed by the Data Handling & Deletion Policy and the Privacy & Personal Data Protection Policy (GDPR erasure). NEEDS INPUT: confirm the technical deletion runbook (who runs it, what proves the tenant is gone) so a deletion can be evidenced. Owner: Thomas/Olaf.
Evidence to capture
Screenshot of the deletion procedure and one completed deletion confirmation if available.
44. Perimeter protection (firewalls, network)¶
CC6.6 · ✅ Done
Perimeter protection is AWS-native: VPC with security groups, no public database exposure, TLS-terminating load balancers, plus Cloudflare in front of web properties. Documented in the Cloud & Infrastructure Security Policy (ISMS-DOC-A08-20-1). Automated check CHK-NET-01 fails any security group opening sensitive ports to 0.0.0.0/0 or ::/0. Owner: Thomas.
Evidence to capture
Screenshot of firewall / security group rules for production.
45. Network segmentation & diagram¶
CC6.6 · 🟡 In progress
Network segregation (prod/staging/dev) is documented in the Cloud & Infrastructure Security Policy + Cloud Architecture reference. NEEDS INPUT: Two open items: staging reportedly shares the production RDS host (OPEN-QUESTIONS Q6 — needs verifying/fixing), and a current network diagram needs producing as evidence. Owner: Thomas.
Evidence to capture
Screenshot of the network diagram showing production separation.
46. Annual firewall rule review¶
CC6.6 · 🟡 In progress
Security-group rules are managed as code (Terraform) and reviewed at change time via PR. NEEDS INPUT: A documented ANNUAL rule review has not yet been performed — schedule one and record it. Automated check CHK-NET-01 monitors continuously. Owner: Thomas.
Evidence to capture
Screenshot of the completed firewall review with date and reviewer.
47. Encryption in transit¶
CC6.7 · ✅ Done
TLS 1.2+ is enforced on all public endpoints; documented in the Cryptographic Policy (ISMS-DOC-A08-24-1). Automated check CHK-TLS-01 scans Soon domains weekly (grade >= A, TLS 1.2+ only, no weak ciphers). Evidence: SSL Labs / testssl output. Owner: Thomas.
Evidence to capture
Screenshot of the valid TLS certificate (padlock/cert details) on your production domain.
48. Encryption at rest¶
CC6.7 · ✅ Done
AES-256 encryption at rest: RDS storage encryption and S3 default encryption (SSE-KMS). Documented in the Cryptographic Policy. Automated checks CHK-ENC-01 (RDS StorageEncrypted) and CHK-ENC-02 (S3 default encryption) verify this daily. Owner: Melvin/Thomas.
Evidence to capture
Screenshot of encryption-at-rest enabled in your database and storage settings.
49. Encryption key management¶
CC6.7 · 🟡 In progress
Keys are managed by AWS KMS (and GCP Secret Manager for application secrets); the Cryptographic Policy covers key handling and was corrected in the lean rewrite to require bcrypt/argon2 for password hashing (previously specified MD5 — now banned along with SHA-1/DES/3DES/RC4). NEEDS INPUT: Confirm the hashing algorithm actually used in the product, and formalise key rotation. Owner: Thomas.
Evidence to capture
Screenshot of the key/secrets manager showing restricted access policies.
50. Endpoint protection & malware defense¶
CC6.8 · ✅ Done
No MDM/EDR (all endpoints are privately-owned BYOD). Compensating control documented in the Device Security Standard (ISMS-DOC-A08-1-3): a 10-point baseline (FileVault, screen lock, auto-update, firewall, XProtect/Gatekeeper, Enpass-only credentials, no local customer data) plus a QUARTERLY VERIFIABLE ATTESTATION — each user runs a set of macOS commands and submits the output + screenshot, so the state is evidenced rather than self-declared. Primary mitigation: all production access requires MFA/SSO, so a lost device alone grants nothing. Trigger to adopt MDM (e.g. Kandji) is documented. Owner: Olaf.
Evidence to capture
Screenshot of MDM dashboard or device settings showing encryption enabled.
CC7 — Operations¶
10 controls: ✅ Done 4 · 🟡 In progress 5 · ⬜ Not started 1
51. Vulnerability & patch management¶
CC7.1 · ✅ Done
AWS GuardDuty is ENABLED in production (742816139593, eu-west-1) with CloudTrail, DNS, VPC flow logs, S3 data events, RDS login events, EBS malware protection and Lambda network logs. Findings at severity >= 4 are routed via EventBridge to the 'soon-security-alerts' SNS topic (email to security@soon.works active; Slack #Security via AWS Chatbot pending a one-time workspace authorisation). Zero open findings as at 2026-08-08. Owner: Thomas/Melvin.
Evidence to capture
Screenshot of dependency/vulnerability alerts enabled in your repo or scanner.
52. Annual penetration test¶
CC7.1 · 🟡 In progress
An independent web application penetration test is INCLUDED in the GetAgency engagement at no additional cost - confirmed in writing by Aman Desai on 2026-08-11 after a scope dispute was raised and settled. (GetAgency also confirmed a pentest is not strictly required for a Type 1; it is being provided regardless.) NEEDS INPUT: awaiting scope, access requirements, timing, deliverables, whether one remediation re-test is included, and whether the report can also support ISO 27001. Sequence the test AFTER the production database is made private (Linear S-299) so the report is not dominated by a known, already-planned finding. Owner: Olaf.
Evidence to capture
Screenshot of the pen test report cover page and the remediation tracker.
53. Hardening standards¶
CC7.1 · 🟡 In progress
Security incidents are evaluated per the Incident Response Procedure (ISMS-DOC-A05-26-1) and detected via GuardDuty -> SNS -> security@soon.works (pipeline tested 2026-08-08). Documented operating procedures now include Production Database Access (ISMS-DOC-A05-37-1). NEEDS INPUT: no incidents have occurred; record a quarterly 'nil return' so there is a positive evidence trail. Owner: Olaf.
Evidence to capture
Screenshot of the hardening standard document with review date.
54. Logging in your cloud environment¶
CC7.2 · ✅ Done
AWS CloudTrail (multi-region, log-file validation) plus CloudWatch logs and Sentry for application errors, per the Logging & Monitoring Policy (ISMS-DOC-A08-15-1). Automated check CHK-LOG-01 verifies CloudTrail is multi-region, validated AND actively logging; CHK-MON-02 checks log-group retention. Owner: Thomas.
Evidence to capture
Screenshot of cloud audit logging enabled and at least one alert rule.
55. Intrusion detection (IDS)¶
CC7.2 · ✅ Done
AWS GuardDuty is ENABLED in the production account (742816139593, eu-west-1) — verified 2026-08-08; it has in fact been running since 2018-05-10. Active protections: CloudTrail, DNS logs, VPC flow logs, EBS malware protection, Lambda network logs, plus S3 data events and RDS login events (both enabled 2026-08-08 to cover Soon's crown-jewel stores). Current state: ZERO open findings. Evidence: get-detector output captured 2026-08-08 (SHA-256 8ad00d95...e54f) for the S3 evidence store; route findings to Slack #Security. Owner: Thomas/Melvin.
Evidence to capture
Screenshot of the IDS/threat-detection service enabled with findings visible.
56. Infrastructure & performance monitoring¶
CC7.2 · ✅ Done
Infrastructure and application monitoring via AWS CloudWatch (metrics + alarms) and Sentry (errors/performance); documented in the Logging & Monitoring Policy. Automated check CHK-MON-01 verifies prod alarms exist and none are in INSUFFICIENT_DATA. Owner: Thomas.
Evidence to capture
Screenshot of the monitoring dashboard and one alert rule or sample alert email.
57. Security incidents evaluated¶
CC7.3 · 🟡 In progress
Information Security Incident Response Procedure (ISMS-DOC-A05-26-1) defines detection, triage, severity and response, with Slack #Security first for speed and email for the paper trail. Status: draft — needs approval. NEEDS INPUT: No incidents recorded to date (a nil-return record is itself useful evidence). Owner: Olaf.
Evidence to capture
Screenshot of the incident log (headers are fine if no incidents).
58. Incident response plan¶
CC7.4 · 🟡 In progress
Incident Response Procedure (ISMS-DOC-A05-26-1) + Personal Data Breach Notification Procedure (ISMS-DOC-A05-34-2, GDPR 72-hour) exist and are Soon-specific. Status: draft — needs owner approval. Owner: Olaf.
Evidence to capture
Screenshot of the approved incident response plan with contact names.
59. Annual incident response test¶
CC7.4 · ⬜ Not started
NEEDS INPUT: no incident-response tabletop test has been run. Schedule a short annual tabletop exercise (a 1-hour walkthrough of a scenario, minuted) — this is an explicit Type 1 evidence item. Owner: Olaf.
Evidence to capture
Screenshot of the dated IR test write-up with attendees and lessons learned.
60. Recovery from incidents (backups & restore test)¶
CC7.5 · 🟡 In progress
Backup Policy (ISMS-DOC-A08-13-1) reflects real RDS facts confirmed by Melvin: automated RDS backups ON with 7-day/30-day retention, PITR currently OFF, no off-account isolation. Automated check CHK-BACKUP-01 verifies retention daily. NEEDS INPUT: A RESTORE TEST HAS NEVER BEEN PERFORMED (OPEN-QUESTIONS Q5) — this is the single highest-priority gap for this control; an auditor will ask for a restore-test record. Owner: Melvin.
Evidence to capture
Screenshot of backup configuration and a successful restore test.
CC8 — Change Management¶
4 controls: ✅ Done 3 · 🟡 In progress 1
61. Change management process¶
CC8.1 · ✅ Done
All changes go through the GitHub PR workflow: branch -> PR -> peer review -> CI checks -> merge, with protected main. Documented in the Change Management Process (ISMS-DOC-A08-32-1). Automated checks CHK-SDLC-01 (branch protection requires review + status checks) and CHK-CHG-01 (no direct pushes to main). Owner: Thomas.
Evidence to capture
Screenshot of repo settings showing required pull-request reviews.
62. Infrastructure changes controlled¶
CC8.1 · ✅ Done
Infrastructure changes are made through Terraform (infrastructure as code) and reviewed via the same PR process — no ad-hoc console changes for managed resources. Documented in the Configuration Management Policy (ISMS-DOC-A08-9-1). Evidence: IaC repo PR history. Owner: Thomas.
Evidence to capture
Screenshot of an infra change PR/ticket showing review and approval.
63. SDLC policy¶
CC8.1 · 🟡 In progress
Secure Development Policy (ISMS-DOC-A08-25-1, absorbed Secure Coding) covers the SDLC: peer review, CI testing, dependency and secret scanning, separation of environments. Status: draft — needs approval. Automated check CHK-SDLC-02 verifies code + secret scanning are enabled. Owner: Thomas.
Evidence to capture
Copy of the approved SDLC policy.
64. Configuration management¶
CC8.1 · ✅ Done
Configuration is managed as code (Terraform) with version history in GitHub; the Configuration Management Policy (ISMS-DOC-A08-9-1) defines baselines and change control. Evidence: IaC repo + PR history. Owner: Thomas.
Evidence to capture
Screenshot of the procedure and a config file/template in your repo.
CC9 — Risk Mitigation¶
4 controls: 🟡 In progress 3 · ⬜ Not started 1
65. Business continuity / disaster recovery plan¶
CC9.1 · 🟡 In progress
Business continuity relies on AWS multi-AZ redundancy and documented backups; the Availability Management Policy (ISMS-DOC-A08-14-1) covers availability. NEEDS INPUT: A formal BC/DR plan with RTO/RPO targets is NOT yet written (ISMS-DOC-A05-30 set is still to create) and RTO/RPO are TODO(owner) — needed for this control. Owner: Olaf/Melvin.
Evidence to capture
Screenshot of the approved BC/DR plan with approval date.
66. Tabletop disaster recovery test (annual)¶
CC9.1 · ⬜ Not started
NEEDS INPUT: no disaster-recovery tabletop test has been run. Pair this with the incident-response tabletop (#59) and the backup restore test (#60) — one session can produce evidence for all three. Owner: Olaf/Melvin.
Evidence to capture
Screenshot of the dated tabletop exercise write-up with attendees and action items.
67. Vendor management & review¶
CC9.2 · 🟡 In progress
Supplier Relationships Policy (ISMS-DOC-A05-19-1) covers due diligence and review; the Information Asset Inventory lists all sub-processors (AWS, Stripe, WorkOS, Intercom, Sentry, Google Workspace, Netlify, PostHog, Aikido, AI providers). NEEDS INPUT: A formal vendor register with review dates + collected SOC 2 reports/DPAs is still to be completed; Intercom's US hosting is an open gap (Linear S-303). Owner: Olaf.
Evidence to capture
Screenshot of the vendor list with risk ratings and review dates.
68. Vendor agreements with confidentiality terms¶
CC9.2 · 🟡 In progress
Vendor agreements/DPAs are in place with the major sub-processors (AWS, Stripe, etc.) as part of their standard terms. NEEDS INPUT: Need to collect and file the signed DPAs/confidentiality terms per vendor as evidence, and confirm which AI providers process customer personal data (OPEN-QUESTIONS Q8). Owner: Olaf.
Evidence to capture
Screenshot of a critical vendor's agreement or ToS showing confidentiality terms.