All 68 controls¶
Every control on the auditor's checklist, with how Soon meets it and the evidence to file. Grouped by Common Criteria series.
Generated from the checklist · last built 2026-10-21.
What makes good evidence
Prefer the document itself. A signed PDF, an exported report, a policy or a contract is stronger than a picture of one — it carries its own dates and signatures. Upload the file; PDFs, text and images are all accepted.
Screenshot when the proof is a live setting — an MFA policy, a console configuration, a dashboard. There is no document to file, so the screen is the artefact.
If you do screenshot, make it count. Include the browser address bar or the
terminal prompt so the account and system are visible — a cropped fragment could
be anything. Show the date: set the menu-bar clock once, then capture the whole
screen with Cmd+Shift+3:
defaults write com.apple.menuextra.clock DateFormat -string "EEE d MMM HH:mm:ss"
killall SystemUIServer
Redact anything sensitive before uploading. Uploads are permanent — a mistake can be superseded but never deleted.
Loading what is already filed…
CC1 — Control Environment¶
12 controls: ✅ Done 9 · ➖ N/A 3
1. Code of conduct & disciplinary policy¶
CC1.1 · ✅ Done
How to set it. Have every employee and contractor sign it.
Code of conduct and disciplinary rules are set by the HR Security Policy (ISMS-DOC-A05-1-2 v0.3, approved 2026-09-04; §2.3 disciplinary process) and the Acceptable Use Policy (ISMS-DOC-A05-10-1 v0.4, approved 2026-10-16), acknowledged on the policy acknowledgement form. Signed acknowledgements: Olaf Jacobson, Thomas Picauly and Alessandro Cardinali (13 Oct 2026); Melvin Jacobson (co-founder, no operating role, 14 Oct 2026); Andrea Cardinali, CyberSquad (signed 14 Oct, countersigned 16 Oct 2026). The earlier screenshot of the internal tool has been withdrawn. Owner: Olaf.
📎 Evidence. Copy of the policy (including the disciplinary section) plus copies of signed acknowledgments from every employee and contractor.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
2. Confidentiality agreements (NDAs)¶
CC1.1 · ✅ Done
How to set it. Collect signatures from everyone at hire.
Everyone with access is bound in writing. The four founders signed the Founder Confidentiality & Security Undertaking (ISMS-DOC-A06-6-3 v0.2), countersigned (13–14 Oct 2026). CyberSquad signed the Consultancy Agreement and the NDA it incorporates (ISMS-DOC-A06-6-2 template) on 14 Oct, countersigned 16 Oct 2026. All are recorded in the Schedule of Confidentiality Agreements (ISMS-DOC-A06-6-1). The 9 Sep pack held only the template. Owner: Olaf.
📎 Evidence. Copies of signed NDAs from every employee and contractor (redact personal details).
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
3. Employment agreements¶
CC1.1 · ✅ Done
How to set it. Have every employee sign one at hire; have a lawyer review it.
Soon has no employees. The three operating founders are directors and shareholders, so their security and confidentiality obligations are set by the Founder Confidentiality & Security Undertaking (ISMS-DOC-A06-6-3 v0.2, approved 2026-09-01). Each of them signed it, countersigned, on 13 Oct 2026, as did co-founder Melvin Jacobson (no operating role) on 14 Oct 2026. Clauses for future employment contracts are set out in ISMS-DOC-A06-2-1. Owner: Olaf.
📎 Evidence. Copies of signed employment agreements for every employee (redact personal details).
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
4. Contractor agreements¶
CC1.1 · ✅ Done
How to set it. Have every contractor sign before starting work.
The only contractor with access is CyberSquad (Andrea Cardinali), external security consultant and internal auditor. The Information Security Consultancy Agreement (ISMS-DOC-A05-20-1 v0.3, approved 2026-10-16) includes the NDA, the access granted (read-only on the ISMS; no production or customer-data access) and return/deletion on exit. Signed by CyberSquad 14 Oct 2026 and countersigned by Soon 16 Oct 2026. Owner: Olaf.
📎 Evidence. Copies of signed contractor agreements for every contractor (redact personal details).
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
5. Board / leadership oversight of security¶
CC1.2 · ✅ Done · 📎 evidence filed
How to set it. Put security on the agenda of a leadership or board meeting at least annually.
Top management (the three operating founders) oversees security through a quarterly security review with a fixed agenda that starts with the privileged access review and an annual management review, per the Management Review Procedure (ISMS-DOC-09-4 v0.3, approved 2026-10-16). Minutes are kept in docs/09-performance/meeting-log. Evidence: minutes of 24 Jul 2026 with attendees and decisions. Owner: Olaf.
📎 Evidence. Screenshot of meeting minutes or the memo showing the date and attendees.
Filed 2026-09-08 11:52:56 UTC by olaf · 5c52b4c12c3830a9…
6. Board charter¶
CC1.2 · ➖ N/A
How to set it. Have the board adopt it.
Soon Technologies B.V. has no separate board: the four founders are the shareholders and the three operating founders are the directors and top management. Oversight is the quarterly security review and annual management review (row 5); the Information Security Policy (ISMS-DOC-05-4) is issued on behalf of top management. Accepted as N/A by GetAgency (Tad Kozusko, 24 Sep 2026).
7. Board expertise documented¶
CC1.2 · ➖ N/A
How to set it. Collect a short bio or CV for each board member showing relevant business/security expertise.
No separate board (see row 6). The founders' roles and security responsibilities are documented in ISMS-DOC-05-2 and the organisation chart ISMS-DOC-05-5. Accepted as N/A by GetAgency (24 Sep 2026).
8. Org chart & defined reporting lines¶
CC1.3 · ✅ Done · 📎 evidence filed
How to set it. Create an org chart showing who reports to whom, including who owns security.
Organisation Chart & Reporting Lines (ISMS-DOC-05-5 v0.1, approved and dated 2026-10-13): shareholders, top management, each founder's role and reporting line, the external consultant's advisory line, with the security owner (Olaf Jacobson, Information Security Manager) marked. It is the picture of ISMS-DOC-05-2. The undated screenshots in the 9 Sep pack have been withdrawn. Owner: Olaf.
📎 Evidence. Screenshot of the current org chart with the security owner labeled.
Filed 2026-09-08 11:55:41 UTC by olaf · 79fc2d55efef7d88…
Filed 2026-09-08 13:14:23 UTC by olaf · 8692b27533d49ddb…
Filed 2026-09-08 13:17:15 UTC by olaf · af59fd7f685b6872…
Filed 2026-09-08 13:21:21 UTC by olaf · d1d19ae051206335…
9. Assign a security owner¶
CC1.3 · ✅ Done
How to set it. Name one person accountable for security.
Olaf Jacobson is the named Information Security Manager, documented in Roles, Responsibilities and Authorities (ISMS-DOC-05-2 v0.3, approved 2026-09-08), the Information Security Policy (ISMS-DOC-05-4) and the organisation chart (ISMS-DOC-05-5). Owner: Olaf.
📎 Evidence. Screenshot of the signed memo or job description.
10. Job descriptions & competence¶
CC1.4 · ✅ Done
How to set it. Write short job descriptions for security-relevant roles.
Roles, Responsibilities and Authorities (ISMS-DOC-05-2 v0.3, approved 2026-09-08) serves as the job descriptions: each person's role, security responsibilities and authorities, with a RACI. Now filed under this row (CC1.4), as the auditor suggested. Competence and training requirements are in ISMS-DOC-07-1 v0.2 (approved 2026-10-16). Owner: Olaf.
📎 Evidence. Screenshot of a job description showing security responsibilities.
11. Background checks¶
CC1.4 · ✅ Done
How to set it. Run a background check on each new hire before their start date using a service like Checkr. Keep the confirmations.
Screening is proportionate to size and risk under HR Security Policy §2.1 (ISMS-DOC-A05-1-2). The founders were not screened, as they founded the company, and Soon has made no non-founder hires. The one external party with access, CyberSquad (Andrea Cardinali), was screened: government ID checked on a video call on 1 Oct 2026, and track record verified from public sources. Recorded in Screening Records (ISMS-FORM-A06-1-2 v0.2, approved 2026-10-13). Future hires follow the Employee Screening Checklist (ISMS-FORM-A06-1-1). Owner: Olaf.
📎 Evidence. Screenshot of a completed background check confirmation (redacted).
12. Performance reviews & accountability¶
CC1.5 · ➖ N/A
How to set it. Hold at least an annual performance review for each employee.
No employees to review: Soon is run by its founders. Accountability runs through the roles in ISMS-DOC-05-2 and the quarterly security review (row 5). To be introduced at the first non-founder hire. Accepted as N/A by GetAgency (24 Sep 2026).
CC2 — Communication¶
11 controls: ✅ Done 9 · 🟡 In progress 1 · ➖ N/A 1
13. Information Security Policy¶
CC2.1 · ✅ Done
How to set it. Have leadership approve and date it.
Information Security Policy (ISMS-DOC-05-4 v0.4, approved 2026-10-16), issued by Olaf Jacobson as founder and ISM on behalf of top management. Communicated via isms.soon.works, security onboarding and the quarterly security review. Owner: Olaf.
📎 Evidence. Copy of the approved policy showing title, version, and approval date.
14. Security awareness training¶
CC2.2 · 🟡 In progress
How to set it. Have every employee complete it annually and log completion.
Training material is ESSENTIALS.md (the twelve security rules plus incident scenarios), delivered through the /isms:onboard session, at onboarding and as an annual refresher (Competence, Awareness & Training Procedure ISMS-DOC-07-1 v0.2, approved 2026-10-16). Completions are recorded in the Security Training & Awareness Log (ISMS-DOC-07-5): Olaf Jacobson and Melvin Jacobson, 8 Sep 2026. Outstanding: Thomas Picauly, Alessandro Cardinali and Andrea Cardinali. Owner: Olaf.
📎 Evidence. Screenshot of the training material and a completion log with names and dates.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
15. Policies shared with all staff¶
CC2.2 · ✅ Done · 📎 evidence filed
How to set it. Store all policies in one shared folder every employee can access, and announce it.
All policies are in one place: the private repository SoonHQ/isms and its site, the Soon Security Handbook (isms.soon.works), behind Cloudflare Access and readable by everyone in scope. Announced to all staff on Slack. Governed by the Control of Documented Information procedure (ISMS-DOC-07-3). Evidence: document register and Slack announcements. Owner: Olaf.
📎 Evidence. Screenshot of the shared policy folder and the announcement message.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
Filed 2026-09-08 11:54:38 UTC by olaf · 7b8fbc312f9e86df…
Filed 2026-09-08 11:54:43 UTC by olaf · 3deb686ae396bf4a…
16. Whistleblower policy & anonymous channel¶
CC2.2 · ➖ N/A
How to set it. Then set up an anonymous reporting form (e.g., a Google Form that doesn't collect emails) and share the link with staff.
Not applicable at current size, with a defined trigger to revisit. With three operating founders and one consultant, an anonymous channel cannot be anonymous, and every route already reaches top management directly: Slack #Security, security@soon.works, or any other founder when the concern is about the ISM. Protections against retaliation are in the HR Security Policy. Trigger: the first non-founder employee. Accepted as N/A by GetAgency (24 Sep 2026). Owner: Olaf.
17. System changes communicated to staff¶
CC2.2 · ✅ Done
How to set it. Announce production changes to the team in a consistent place (release-notes channel or email).
Product and system changes are announced to the team on Slack and tracked in Linear and GitHub pull requests, per the Change Management Process (ISMS-DOC-A08-32-1 v0.3, approved 2026-10-16). Evidence: Slack announcements of a release. Owner: Thomas.
📎 Evidence. Screenshot of a recent internal release note or changelog message.
18. Customer-facing security commitments¶
CC2.3 · ✅ Done
How to set it. Publish your privacy policy and terms of service on your website.
Security commitments to customers are published at https://soon.works/legal/terms, https://soon.works/legal/privacy, https://soon.works/legal/gdpr and https://soon.works/legal/dpa (including Annex II, technical and organisational measures). They state the real MFA position and infrastructure. Owner: Olaf.
📎 Evidence. Screenshot of the live privacy policy page with the URL visible.
19. Master Service Agreement (MSA)¶
CC2.3 · ✅ Done · 📎 evidence filed
How to set it. Have a lawyer review before using.
Self-serve customers accept Soon's standard Terms of Service and DPA, published at https://soon.works/legal/terms and https://soon.works/legal/dpa, which carry the confidentiality, data-protection and security commitments. Enterprise customers sign a negotiated agreement; signed PDFs are held in Google Drive. Evidence: extracts of a signed MSA confidentiality clause and a signed customer DPA. Owner: Olaf.
📎 Evidence. Screenshot of the MSA template showing the security commitments section.
Filed 2026-09-09 09:32:51 UTC by olaf · 86868ffe8ac3690b…
20. System Description¶
CC2.3 · ✅ Done
How to set it. Your auditor includes this in the report, so have leadership approve it.
System Description (ISMS-DOC-04-2 v0.4, approved 2026-10-16): service and boundaries, components in and out of scope, data processed, infrastructure verified against the live AWS account, sub-processors, control environment, known limitations and complementary user entity controls. Owner: Olaf.
📎 Evidence. Screenshot of the approved system description document with date.
21. Channel for reporting security concerns¶
CC2.3 · ✅ Done
How to set it. Set up security@yourcompany.com (or a form) for anyone to report issues, and list it on your site.
Security concerns are reported in Slack #Security, with security@soon.works as the email route, also published on the website for outside reporters, per the Information Security Event Reporting Procedure (ISMS-DOC-A06-8-1 v0.3, approved 2026-09-01). Owner: Olaf.
📎 Evidence. Screenshot of the security contact published on your website.
22. Customer support channel¶
CC2.3 · ✅ Done
How to set it. Publish a support email or help page where customers can report failures, incidents, or complaints.
Customer support runs through Intercom (in-product messenger and email), the help centre and the website contact page, staffed by the founders. Owner: Olaf.
📎 Evidence. Screenshot of the live support page or support email address on your site.
23. Customers notified of critical changes¶
CC2.3 · ✅ Done
How to set it. Email or post product updates when changes may affect customers.
Customers are told of critical changes through the in-app and public changelog and by email, and of availability incidents on the status page https://status.soon.works/. Incident communication is set by the Incident Response Procedure (ISMS-DOC-A05-26-1, approved 2026-09-01); personal-data breaches are notified to customers within 48 hours (24 hours where a contract requires it), per the DPA §8. Owner: Olaf.
📎 Evidence. Screenshot of a recent customer update email or changelog post.
CC3 — Risk Assessment¶
4 controls: ✅ Done 4
24. Defined business & security objectives¶
CC3.1 · ✅ Done
How to set it. Write down your security objectives (e.g., protect customer data, 99.9% uptime).
Information Security Objectives & Plan (ISMS-DOC-06-1 v0.4, approved 2026-10-16): measurable objectives with owners and target dates, including ISO/IEC 27001 certification by Q1 2027. Measured as defined in ISMS-DOC-09-1 and reviewed at the quarterly security review. Owner: Olaf.
📎 Evidence. Screenshot of the documented objectives with an approval date.
25. Annual risk assessment¶
CC3.2 · ✅ Done
How to set it. Save the output as a dated document and repeat yearly.
Risk Assessment Report (ISMS-DOC-06-3 v0.8, approved 2026-10-16): 31 risks scored for likelihood and impact, each with an owner, a treatment and a residual score. Reviewed annually and on significant change. Owner: Olaf.
📎 Evidence. Screenshot of the completed, dated risk assessment.
26. Fraud risk considered¶
CC3.3 · ✅ Done
How to set it. Add a fraud section to your risk assessment.
Fraud risk is assessed in its own section of the Risk Assessment Report (ISMS-DOC-06-3 v0.8): fraud against Soon (R-24 insider misuse of privileged access, R-25 billing manipulation, R-28 invoice/CEO fraud), using Soon's systems (R-27 admin account takeover) and through the product (R-26 time and schedule manipulation). It records the segregation-of-duties limit of a three-founder team and the detective controls that compensate (CloudTrail and GuardDuty, quarterly access reviews, release review). Owner: Olaf.
📎 Evidence. Screenshot of the fraud risk section of your risk assessment.
27. Assess impact of major changes¶
CC3.4 · ✅ Done
How to set it. Before big changes (new vendor, new product, re-architecture), note the security impact.
Change Management Process (ISMS-DOC-A08-32-1 v0.3, approved 2026-10-16): changes go through pull requests and CI; every release to production is reviewed by a second founder; emergency changes are reviewed within 5 working days. Changes with security impact are assessed against the risk register. Owner: Thomas.
📎 Evidence. Screenshot of a completed change risk questionnaire.
CC4 — Monitoring¶
2 controls: ✅ Done 2
28. Periodic control self-assessment¶
CC4.1 · ✅ Done
How to set it. Once or twice a year, walk this checklist and confirm each control still works.
Control Self-Assessment, October 2026 (ISMS-FORM-09-9, approved 2026-10-13): every one of the 68 controls assessed against the evidence, with the open items and their owners. It corrected rows the 9 Sep sheet had marked Done without evidence. Repeated quarterly. Independent internal audits are run by CyberSquad under the Procedure for Internal Audits (ISMS-DOC-09-2). Owner: Olaf.
📎 Evidence. Screenshot of the completed self-assessment with date and reviewer.
29. Track and remediate deficiencies¶
CC4.2 · ✅ Done · 📎 evidence filed
How to set it. Keep a simple issue log for any control gaps found, with owner and due date.
Deficiencies are tracked to closure in Linear (project 'SOC 2 Type 1 — audit readiness') with an owner, status and evidence. Nonconformities follow ISMS-DOC-10-1 and are logged in the Nonconformity & Corrective Action Log (ISMS-FORM-10-1), with root cause, corrective action and a check that it worked. Penetration test findings and their treatment: ISMS-FORM-A08-8-3. Owner: Olaf.
📎 Evidence. Screenshot of the issue log showing at least the column headers and status.
Filed 2026-09-08 11:57:34 UTC by olaf · 166c82ee5a99f0b3…
CC5 — Control Activities¶
3 controls: ✅ Done 3
30. Controls mapped to risks¶
CC5.1 · ✅ Done
How to set it. In your risk assessment, note which control addresses each risk.
Controls are mapped to risks in the Statement of Applicability (ISMS-FORM-06-2, approved 2026-09-01: all 93 ISO/IEC 27001 Annex A controls with applicability and justification) and the per-risk treatments in the Risk Assessment Report (ISMS-DOC-06-3). Owner: Olaf.
📎 Evidence. Screenshot of the risk register showing a controls column.
31. Technology controls selected¶
CC5.2 · ✅ Done
How to set it. Document your baseline tech controls (MFA, encryption, backups, logging).
Technology controls are selected in the Statement of Applicability and documented in the A.8 policy set (access control, cryptography, logging, backup, network and cloud security, secure development), implemented on AWS, Cloudflare and GitHub. Owner: Thomas.
📎 Evidence. Screenshot of the technical controls summary document.
32. Policies enacted through procedures¶
CC5.3 · ✅ Done
How to set it. Each policy should say who does what and how often.
Every policy has an owner, responsibilities and a review date in its front matter, and is approved by the ISM. Procedures put the policies into practice: incident response, production database access, evidence collection, access reviews, change management. Owner: Olaf.
📎 Evidence. Copy of a policy showing responsibilities and review frequency.
CC6 — Access¶
18 controls: ✅ Done 16 · 🟡 In progress 2
33. Access control policy & least privilege¶
CC6.1 · ✅ Done
How to set it. Build a simple matrix of who gets what.
Access Control Policy (ISMS-DOC-A05-15-1 v0.5, approved 2026-09-29, owner Thomas): least privilege, role-based access, MFA, joiner/mover/leaver, quarterly access reviews. Owner: Thomas.
📎 Evidence. Copy of the approved policy plus the access matrix.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
34. MFA on all critical systems¶
CC6.1 · ✅ Done · 📎 evidence filed
How to set it. Turn on multi-factor authentication for email, cloud hosting, code repos, and admin tools.
MFA is required on the systems that matter: AWS (IAM Identity Center), GitHub (two-factor enforced organisation-wide, every member compliant, evidence captured), Google Workspace and the other tools shown. Product note for the auditor: email/password customer accounts have no native MFA yet (risk R-22, disclosed); SSO and Google/Microsoft login are offered, inheriting the identity provider's MFA. A GitHub screenshot taken before 2FA was enforced has been withdrawn. Owner: Thomas.
📎 Evidence. Screenshot of MFA enforcement settings in each critical system.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
Filed 2026-09-08 15:25:10 UTC by olaf · c7b70dee4fc463e4…
35. Password manager & password policy¶
CC6.1 · ✅ Done
How to set it. Roll out a password manager (e.g., 1Password) to all staff.
Enpass is the company password manager, used to generate and store credentials. Password requirements (length, uniqueness, no reuse) are in the Access Control Policy (ISMS-DOC-A05-15-1). Owner: Olaf.
📎 Evidence. Screenshot of the password manager admin console showing active users.
36. Data classification policy¶
CC6.1 · ✅ Done
How to set it. Share it with the team.
Information Classification Procedure (ISMS-DOC-A05-12-1, approved 2026-09-09): Public, Internal, Confidential and Restricted, with handling rules. Every ISMS document carries its classification. Owner: Olaf.
📎 Evidence. Copy of the approved data classification policy.
37. Production asset inventory¶
CC6.1 · ✅ Done
How to set it. Keep a list of your production systems: servers, databases, storage, key SaaS tools.
Asset Management Policy (ISMS-DOC-A05-9-1 v0.3, approved 2026-10-16) and the Information Asset Inventory: AWS eu-west-1 (ECS Fargate, RDS MySQL, ElastiCache, S3, SES, CloudWatch), Cloudflare (DNS, WAF, Pages), the SaaS sub-processors and endpoints, each with an owner. Reviewed annually and on significant change. Owner: Olaf.
📎 Evidence. Screenshot of the asset inventory list with an updated date.
38. Access provisioning on hire¶
CC6.2 · ✅ Done · 📎 evidence filed
How to set it. Grant access only via your onboarding checklist, approved by a manager.
Access is granted by role, approved by the ISM, and recorded, under the Access Control Policy (ISMS-DOC-A05-15-1). No new joiners since the ISMS started. Evidence: the Q3 2026 access provisioning and review record. Owner: Thomas.
📎 Evidence. Screenshot of a completed onboarding checklist for a recent hire.
Filed 2026-09-09 13:26:46 UTC by olaf · 7ce0dd5f41d41780…
39. Access removal on departure & quarterly review¶
CC6.3 · ✅ Done · 📎 evidence filed
How to set it. Remove all access the day someone leaves, and review all accounts quarterly.
Leavers lose access the same day, following the Termination & Change of Employment Checklist (ISMS-FORM-A06-5-1). Access is reviewed quarterly: the Q3 2026 review of AWS and GitHub was performed and closed with the actions taken (evidence). Owner: Thomas.
📎 Evidence. Screenshot of a completed offboarding checklist and the latest access review.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
Filed 2026-09-09 13:26:41 UTC by olaf · 7ce0dd5f41d41780…
Filed 2026-09-09 14:09:52 UTC by olaf · da3c1c90dd293665…
Filed 2026-09-09 14:21:25 UTC by olaf · af4c83860e50d6c1…
40. Physical access / office & devices¶
CC6.4 · ✅ Done · 📎 evidence filed
How to set it. If you have an office, limit entry (locks, badges) and record who has keys. Fully remote? Document that in your security policy.
Fully remote, no offices: physical security of production is AWS's. Device and workplace rules: Clear Desk & Clear Screen Policy (ISMS-DOC-A07-7-1), Remote Working Policy (ISMS-DOC-A06-7-1) and Device Security Standard (ISMS-DOC-A08-1-3), all approved 2026-09-01, with signed device attestations. Owner: Olaf.
📎 Evidence. Copy of the physical security section, or the badge/key holder list.
Filed 2026-09-08 21:21:47 UTC by olaf · 34ebc09a3439ba11…
41. Secure disposal of data & devices¶
CC6.5 · ✅ Done
How to set it. Wipe or destroy devices and media before disposal.
Data: the Data Handling & Deletion Policy (ISMS-DOC-A08-10-1 v0.2, approved 2026-09-09) and the Records Retention & Protection Policy (ISMS-DOC-A05-33-1) set how data is deleted and when. Devices: all endpoints are personally owned. Device Security Standard §3.1 (ISMS-DOC-A08-1-3 v0.2, approved 2026-10-21): a device that leaves its owner's hands (sold, given away, traded in or thrown away) is fully erased first (Erase All Content and Settings, which destroys the FileVault key); someone who leaves Soon but keeps their device signs out, removes Soon credentials and deletes local Soon files. Either is confirmed in writing, at exit on the termination checklist (ISMS-FORM-A06-5-1 v0.3, row 6). Owner: Olaf.
📎 Evidence. Screenshot of the disposal procedure and one wipe confirmation if available.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
42. Data retention & disposal procedures¶
CC6.5 · ✅ Done
How to set it. Have leadership approve it.
Records Retention & Protection Policy (ISMS-DOC-A05-33-1 v0.4, approved 2026-09-01) with the retention schedule (7 years for fiscal and payroll records, 5 years for contracts, per Dutch law). Deletion methods are in the Data Handling & Deletion Policy (ISMS-DOC-A08-10-1). Owner: Olaf.
📎 Evidence. Copy of the approved retention policy showing the retention schedule.
43. Customer data deletion on departure¶
CC6.5 · ✅ Done
How to set it. Document how customer data is purged when a customer leaves, and follow it.
Customer data after contract end: export for 30 days, then deletion from live systems within a further 60 days (90 days in total), with backups aged out within 30 days after that. Deletion is confirmed in writing on request (DPA §9, https://soon.works/legal/dpa). Governed by the Data Handling & Deletion Policy (ISMS-DOC-A08-10-1) and the Records Retention & Protection Policy (ISMS-DOC-A05-33-1). Owner: Thomas/Olaf.
📎 Evidence. Screenshot of the deletion procedure and one completed deletion confirmation if available.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
44. Perimeter protection (firewalls, network)¶
CC6.6 · ✅ Done · 📎 evidence filed
How to set it. Use your cloud provider's firewall/security groups to block everything not needed.
Perimeter protection: production runs in a VPC where only the load balancer is reachable from the internet (80/443), the database has no public endpoint, and services accept traffic from the load balancer only. The web application is served through Cloudflare (WAF, DDoS protection). Security headers are enforced. Documented in the Cloud & Infrastructure Security Policy (ISMS-DOC-A08-20-1). Owner: Thomas.
📎 Evidence. Screenshot of firewall / security group rules for production.
Filed 2026-08-24 09:07:16 UTC by olaf · 0223c12771a0a01b…
45. Network segmentation & diagram¶
CC6.6 · 🟡 In progress · 📎 evidence filed
How to set it. Separate production from everything else (VPCs/subnets) and draw a simple network diagram.
Network Architecture & Segmentation (ISMS-DOC-A08-22-1): diagram and zone table drawn from the OpenTofu code that defines the network and checked against live DNS/TLS. Public subnets (load balancer, NAT) and private subnets (services, database, cache). Development is in a separate VPC with no peering. Staging (Azure) holds no production data (confirmed 2026-09-09). The log-archive account is isolated. Known gaps are shown, not hidden. Corrected on 21 October 2026 from a live check: the production database sits in the account's default VPC, reached over a peering connection, with no public endpoint. Awaiting technical review by Thomas Picauly (CTO) and approval, expected by 23 October 2026; the approved diagram follows then. Evidence: no database port open to the internet. Owner: Thomas.
📎 Evidence. Screenshot of the network diagram showing production separation.
Filed 2026-08-24 09:07:28 UTC by olaf · ce40d3d204095e82…
46. Annual firewall rule review¶
CC6.6 · 🟡 In progress · 📎 evidence filed
How to set it. Once a year, review firewall/security-group rules, remove anything unneeded, and limit who can change them.
Security-group rules are code (OpenTofu), reviewed in a pull request whenever they change, and checked continuously by CHK-NET-01 for anything open to the internet. Annual review: the production security-group rules were exported (evidence) and the 2026 review record (ISMS-FORM-A08-20-2) has been prepared from that export, awaiting sign-off by Thomas Picauly (expected by 23 October 2026). Its six findings include none reachable from the internet; the approved record follows then. Owner: Thomas.
📎 Evidence. Screenshot of the completed firewall review with date and reviewer.
Filed 2026-09-08 13:26:07 UTC by olaf · a553161bd8f84e77…
47. Encryption in transit¶
CC6.7 · ✅ Done · 📎 evidence filed
How to set it. Enforce HTTPS/TLS on your website, product, and internal tools — no plain HTTP.
TLS 1.2 or higher on every public endpoint, per the Cryptographic Policy (ISMS-DOC-A08-24-1). The API load balancer refuses all legacy CBC and RSA-key-exchange suites (evidence). Penetration test finding #1 (Low): some legacy TLS 1.2 suites are still offered on Cloudflare Pages hostnames such as app.soon.works, which serve only static application files. A zone-wide restriction was applied and re-tested on 16 Oct 2026; Cloudflare does not allow cipher control on Pages hostnames, so the finding is formally risk-accepted in ISMS-FORM-A08-8-3 v0.2 (approved 2026-10-16), with re-test evidence under row 52. Owner: Thomas.
📎 Evidence. Screenshot of the valid TLS certificate (padlock/cert details) on your production domain.
Filed 2026-09-02 15:58:27 UTC by olaf · 5640a1ebd0578b53…
48. Encryption at rest¶
CC6.7 · ✅ Done
How to set it. Turn on encryption at rest for every production database, storage bucket, and disk — most cloud providers make this one setting.
AES-256 encryption at rest everywhere (captured 21 Oct 2026): both RDS instances, with their backups and snapshots, encrypted with AWS KMS customer-managed keys; every S3 bucket in the production account encrypted by default, with SSE-KMS on the application data buckets and S3-managed AES-256 on the rest. Documented in the Cryptographic Policy (ISMS-DOC-A08-24-1). Checked by CHK-ENC-01 and CHK-ENC-02. Owner: Thomas.
📎 Evidence. Screenshot of encryption-at-rest enabled in your database and storage settings.
49. Encryption key management¶
CC6.7 · ✅ Done · 📎 evidence filed
How to set it. Store keys and secrets in a managed service (e.g., AWS KMS/Secrets Manager) and restrict access to those who need it.
Keys are held in AWS KMS (customer-managed keys, inventory captured as evidence), and production secrets in AWS Secrets Manager. Passwords are hashed with bcrypt, verified in the product source on 2026-08-22. Key handling and the banned algorithms are in the Cryptographic Policy (ISMS-DOC-A08-24-1). Owner: Thomas.
📎 Evidence. Screenshot of the key/secrets manager showing restricted access policies.
Filed 2026-09-08 11:53:02 UTC by olaf · bf33da08e0232336…
50. Endpoint protection & malware defense¶
CC6.8 · ✅ Done · 📎 evidence filed
How to set it. Require disk encryption (including removable media), screen lock, auto-updates, and malware protection on all work laptops (an MDM makes this easy).
No MDM/EDR: all endpoints are personally owned. The compensating control is the Device Security Standard (ISMS-DOC-A08-1-3): a 10-point baseline (FileVault, screen lock, automatic updates, firewall, XProtect/Gatekeeper, password manager only, no local customer data) with a quarterly attestation that captures command output and screenshots, so the state is evidenced rather than self-declared. Production access needs MFA, so a lost device alone grants nothing. Owner: Olaf.
📎 Evidence. Screenshot of MDM dashboard or device settings showing encryption enabled.
Filed 2026-09-08 21:21:18 UTC by olaf · 34ebc09a3439ba11…
CC7 — Operations¶
10 controls: ✅ Done 8 · 🟡 In progress 2
51. Vulnerability & patch management¶
CC7.1 · ✅ Done
How to set it. Turn on automatic updates and dependency alerts (e.g., Dependabot).
Technical Vulnerability & Threat Management Policy (ISMS-DOC-A08-8-1 v0.3, approved 2026-10-16) with fix deadlines by severity. Dependabot alerts and security updates are enabled on the repositories, and AWS GuardDuty is enabled in production with findings routed to security@soon.works. Owner: Thomas.
📎 Evidence. Screenshot of dependency/vulnerability alerts enabled in your repo or scanner.
52. Annual penetration test¶
CC7.1 · ✅ Done · 📎 evidence filed
How to set it. Hire a pen-test firm once a year and fix critical/high findings on a deadline.
Independent web application penetration test by Agency Cyber Inc. (GetAgency), authenticated, against production: app.soon.works and the API, tested 21–22 Sep 2026, report v1.0 dated 24 Sep 2026. Overall low risk: 0 critical, 0 high, 0 medium, 1 low, 3 informational. Remediation and formal risk acceptance: ISMS-FORM-A08-8-3 v0.2 (approved 2026-10-16), tracked in Linear S-606 to S-611. Repeated annually under the Penetration Testing Procedure (ISMS-DOC-A08-8-2). Owner: Olaf.
📎 Evidence. Screenshot of the pen test report cover page and the remediation tracker.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
Filed 2026-09-08 11:58:43 UTC by olaf · 9810001a28bd50c8…
Filed 2026-09-08 12:01:09 UTC by olaf · 1db42c79d2edc22d…
53. Hardening standards¶
CC7.1 · ✅ Done
How to set it. Document your baseline server/system hardening settings and review annually.
Device Security Standard (ISMS-DOC-A08-1-3: BYOD baseline with quarterly attestation) and Cloud & Infrastructure Security Policy (ISMS-DOC-A08-20-1), both approved 2026-09-01. Baselines are enforced as code under the Configuration Management Policy (ISMS-DOC-A08-9-1). Owner: Thomas.
📎 Evidence. Screenshot of the hardening standard document with review date.
54. Logging in your cloud environment¶
CC7.2 · ✅ Done
How to set it. Turn on audit/activity logging in your cloud environment (e.g., AWS CloudTrail, Google Cloud Audit Logs, Azure Activity Log) with alerts on suspicious activity.
AWS CloudTrail (organisation trail, all regions, log-file validation), stored in a separate log-archive account; CloudWatch logs and Sentry for application errors, per the Logging & Monitoring Policy (ISMS-DOC-A08-15-1). CHK-LOG-01 verifies that CloudTrail is logging. Owner: Thomas.
📎 Evidence. Screenshot of cloud audit logging enabled and at least one alert rule.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
55. Intrusion detection (IDS)¶
CC7.2 · ✅ Done
How to set it. Enable an intrusion detection service in your cloud (e.g., AWS GuardDuty, Google Security Command Center, Azure Defender) and route findings to email or Slack.
AWS GuardDuty is enabled in the production account (running since 2018), covering CloudTrail, DNS, VPC flow logs, EBS malware protection, Lambda network activity, S3 data events and RDS logins. Findings of severity 4 or higher go to security@soon.works. Owner: Thomas.
📎 Evidence. Screenshot of the IDS/threat-detection service enabled with findings visible.
56. Infrastructure & performance monitoring¶
CC7.2 · ✅ Done
How to set it. Set up uptime/performance monitoring with alert thresholds (e.g., CloudWatch, Datadog, UptimeRobot).
Infrastructure and application monitoring through AWS CloudWatch (metrics and alarms) and Sentry (errors and performance), per the Logging & Monitoring Policy (ISMS-DOC-A08-15-1). CHK-MON-01 verifies that production alarms exist and report data. Owner: Thomas.
📎 Evidence. Screenshot of the monitoring dashboard and one alert rule or sample alert email.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
57. Security incidents evaluated¶
CC7.3 · ✅ Done
How to set it. Keep an incident log — even if empty — noting date, impact, and resolution for any event.
Every security event is triaged and evaluated under the Information Security Incident Response Procedure (ISMS-DOC-A05-26-1, approved 2026-09-01) and recorded in the Security Incident Register (ISMS-FORM-10-2, approved 2026-10-13), which includes INC-2025-01 (abuse of invitation emails, Feb–Mar 2025) and what changed afterwards. Owner: Olaf.
📎 Evidence. Screenshot of the incident log (headers are fine if no incidents).
58. Incident response plan¶
CC7.4 · ✅ Done
How to set it. Share it with the team.
Information Security Incident Response Procedure (ISMS-DOC-A05-26-1, approved 2026-09-01) with named roles and contacts, plus playbooks for ransomware, denial of service and data breach (ISMS-DOC-A05-24-1/2/3). Personal-data breaches follow the breach notification procedure (ISMS-DOC-A05-34-2). Owner: Olaf.
📎 Evidence. Screenshot of the approved incident response plan with contact names.
59. Annual incident response test¶
CC7.4 · 🟡 In progress
How to set it. Test your incident response plan once a year — this can be combined with your DR tabletop exercise.
Annual incident-response test: a scenario exercise based on the September 2026 penetration test (credential stuffing against password logins, leading to a personal-data breach), run against the real procedures by the three operating founders. Exercise pack and minutes: ISMS-FORM-A05-30-2. Scheduled for Friday 23 October 2026, 14:00–15:50 CEST, with the three operating founders (exercise pack issued; Linear S-692), together with rows 60 and 66. The approved minutes, with attendees, timeline, lessons and actions, will be sent as soon as they are signed off. Owner: Olaf.
📎 Evidence. Screenshot of the dated IR test write-up with attendees and lessons learned.
60. Recovery from incidents (backups & restore test)¶
CC7.5 · 🟡 In progress
How to set it. Turn on automated backups for production data and test a restore once a year.
Backup Policy (ISMS-DOC-A08-13-1 v0.3, approved 2026-10-16): automated, encrypted RDS backups with point-in-time recovery, and a restore test at least once a year. The first restore test (S-412) is a live point-in-time restore of production into an isolated instance, timed and verified (row counts, latest record, a known lookup) against the RTO of 8 hours and RPO of 24 hours. Recorded in ISMS-FORM-A05-30-2 with screenshots. Scheduled for 23 October 2026 (Linear S-692). Evidence already in the pack: the current backup configuration (30-day retention, Multi-AZ, encrypted) and the daily automated snapshots, captured 21 October 2026. Owner: Thomas.
📎 Evidence. Screenshot of backup configuration and a successful restore test.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
CC8 — Change Management¶
4 controls: ✅ Done 4
61. Change management process¶
CC8.1 · ✅ Done
How to set it. Require code review and approval before production changes; use separate dev/prod environments.
Changes reach production through GitHub pull requests with CI checks, on branches protected by rulesets (evidence). Every release to production is reviewed by a second founder, and emergency changes are reviewed within 5 working days (Change Management Process ISMS-DOC-A08-32-1 v0.3, approved 2026-10-16). Owner: Thomas.
📎 Evidence. Screenshot of repo settings showing required pull-request reviews.
62. Infrastructure changes controlled¶
CC8.1 · ✅ Done
How to set it. Make infrastructure changes through code or documented tickets, not ad-hoc console edits.
Infrastructure is defined in OpenTofu (Terraform-compatible) in SoonHQ/soon-terraform and changed through the same pull-request process. No manual console changes for managed resources. Configuration Management Policy (ISMS-DOC-A08-9-1). Evidence: an infrastructure pull request. Owner: Thomas.
📎 Evidence. Screenshot of an infra change PR/ticket showing review and approval.
63. SDLC policy¶
CC8.1 · ✅ Done
How to set it. Have the engineering lead approve it.
Secure Development Policy (ISMS-DOC-A08-25-1 v0.3, approved 2026-10-16): review, CI testing, dependency and secret scanning, and separated environments. CHK-SDLC-02 verifies that code and secret scanning are enabled. Owner: Thomas.
📎 Evidence. Copy of the approved SDLC policy.
64. Configuration management¶
CC8.1 · ✅ Done
How to set it. Define system configurations in code or templates (e.g., Terraform, Docker) so environments stay consistent.
Configuration is managed as code with version history in GitHub, per the Configuration Management Policy (ISMS-DOC-A08-9-1, approved 2026-09-08): baselines, change control and drift. Owner: Thomas.
📎 Evidence. Screenshot of the procedure and a config file/template in your repo.
Several artefacts expected — upload one per system or person. A signed PDF or the original document beats a screenshot of it.
CC9 — Risk Mitigation¶
4 controls: ✅ Done 3 · 🟡 In progress 1
65. Business continuity / disaster recovery plan¶
CC9.1 · ✅ Done
How to set it. Have leadership approve it. Consider cyber insurance.
Business Continuity & Disaster Recovery Plan (ISMS-DOC-A05-30-1 v0.2, approved 2026-10-16): 99.5% availability target, RTO 8 hours, RPO 24 hours, recovery steps, Thomas Picauly as recovery lead and Olaf Jacobson as deputy. Supported by the Availability Management Policy (ISMS-DOC-A08-14-1). The 9 Sep pack attached only the availability policy; the plan is now included. Owner: Thomas.
📎 Evidence. Screenshot of the approved BC/DR plan with approval date.
66. Tabletop disaster recovery test (annual)¶
CC9.1 · 🟡 In progress
How to set it. Once a year, gather the team and walk through a disaster scenario against your BC/DR plan, then write down what happened and what you'll fix.
Annual disaster-recovery tabletop: a scenario walking BC/DR plan §4 (a faulty migration corrupting schedules for all tenants, with the recovery lead unreachable, testing the deputy arrangement), using the live restore timings from row 60. Exercise pack and minutes: ISMS-FORM-A05-30-2, held in the same session as rows 59 and 60 on Friday 23 October 2026 (Linear S-692). Minutes follow when approved. Owner: Olaf.
📎 Evidence. Screenshot of the dated tabletop exercise write-up with attendees and action items.
67. Vendor management & review¶
CC9.2 · ✅ Done
How to set it. List every vendor, rank by risk, and collect SOC 2 reports from critical ones annually.
Vendor & Sub-processor Register (ISMS-FORM-A05-19-1 v0.7, approved 2026-10-16): every vendor with purpose, data processed, region, criticality, agreement status and open actions. Supplier Relationships Security Policy (ISMS-DOC-A05-19-1) sets the annual review. Owner: Olaf.
📎 Evidence. Screenshot of the vendor list with risk ratings and review dates.
68. Vendor agreements with confidentiality terms¶
CC9.2 · ✅ Done
How to set it. Keep a signed agreement or accepted terms of service on file for each critical vendor, confirming it includes confidentiality/privacy commitments.
The core sub-processors' data processing agreements and confidentiality terms are collected and listed in the DPA collection manifest (evidence). The open items are recorded in the vendor register, not hidden: the countersigned PostHog DPA and the OpenAI API DPA (S-411). Internal AI assistants are used on paid individual plans under consumer terms, which carry no DPA; this is disclosed, risk-assessed and accepted (risk R-29, vendor action V-10, Acceptable Use Policy §2.6). Owner: Olaf.
📎 Evidence. Screenshot of a critical vendor's agreement or ToS showing confidentiality terms.