Skip to content

Penetration Testing Procedure

Purpose. How Soon commissions, runs and acts on penetration tests, so that findings are genuinely fixed and the test itself produces audit evidence. Covers A.8.8 (technical vulnerabilities), A.8.29 (security testing) and A.5.35 (independent review); SOC 2 CC7.1.

Status: DRAFT — written ahead of the first test. GetAgency confirmed on 2026-08-11 that an independent web application penetration test is included at no cost. This procedure is what we follow to run it.

1. Cadence and scope

  • At least annually, and after any material change to authentication, tenant isolation, payments, or the public attack surface.
  • Default scope: the customer-facing web application and its API — this is what the SOC 2 auditor expects and what an attacker actually reaches.
  • Infrastructure, social engineering and physical testing are out of scope unless separately commissioned. Soon has no offices, so physical testing is not applicable.

2. Before the test — preconditions

These matter more than people expect. A test run against a known-broken environment produces a report full of findings you already knew about, which then have to be remediated and re-tested. Fix the known items first.

# Precondition Why Status
1 Production database is private (Linear S-299, blocked by S-371) The single largest known exposure. A test run today would lead the report with it Blocking
2 Critical and high vulnerabilities from Aikido/Dependabot within SLA Known, already-triaged issues should not consume the test Check before booking
3 Test accounts provisioned (below) Unauthenticated testing only covers the login page Before start
4 Team notified Alerts will fire; they must not be handled as a real incident Day before
5 Snapshot taken if testing against production Cheap insurance against a destructive payload Day of

3. What the tester needs from us

Agree in writing before the test starts:

  • Targets — exact domains, application URLs and API base paths in scope, and anything explicitly out of scope.
  • Environment — production or a production-like staging environment. Testing production gives the truest result; staging avoids customer impact. State which, and why.
  • Test accounts — at minimum two accounts in different tenants, plus one of each role (Owner, Admin, Member). Two tenants is what makes it possible to test the thing that matters most to a WFM platform: tenant isolation.
  • API access — an API token with documented scopes, and the OpenAPI specification.
  • Rate limiting — whether limits should be relaxed for the tester's source IPs, and which IPs those are.
  • Contact and escalation — a named contact reachable during testing, and an agreed signal for stopping immediately if something breaks.
  • Timing window — dates, and whether testing outside business hours is preferred.

4. What we should expect back

Agree these deliverables before the engagement, not after:

  • A written report with scope, dates, methodology, findings with severity, evidence and remediation advice — an auditor reads the scope section as carefully as the findings.
  • An executive summary that can be shared with customers under NDA.
  • One remediation re-test after fixes, and a statement confirming closure. Without a re-test you can show the finding but not the fix.
  • Confirmation of whether the report can also support ISO/IEC 27001 certification.

5. Rules of engagement

  • No destructive testing without explicit written agreement: no data deletion, no denial-of-service, no sustained load testing.
  • Customer data must not be exfiltrated. Demonstrating access is sufficient; copying real personal data is not acceptable and would itself be a personal data breach.
  • AWS: customer-initiated penetration testing of your own resources is permitted for common services without prior approval, but stress and DDoS testing require AWS authorisation. Keep the test within the permitted set.
  • If the tester finds something critical and actively exploitable, they should tell us immediately rather than waiting for the report.

6. During the test

  • Expect GuardDuty findings and CloudWatch alarms. Do not silence monitoring — instead, note in the incident channel that a test is running, so alerts are recognised rather than ignored. A test that triggers no detections at all is worth asking about.
  • Record the start and end times; they belong in the evidence.

7. After the test — remediation

  1. Log every finding as a Linear issue, security-labelled, with the severity the tester assigned.
  2. Remediate to the SLA in the Vulnerability & Threat Management Policy: Critical 7 days · High 30 days · Medium 90 days · Low next release.
  3. Where a finding is accepted rather than fixed, record it as a risk with a rationale and an owner — a documented accepted risk is defensible; a silently ignored finding is not.
  4. Run the re-test and file the confirmation.
  5. Feed material findings into the risk register and raise them at the next management review.
  6. Index the report and the re-test in the Evidence Register under A.8.8 / CC7.1.

8. Roles

  • Thomas Picauly — owns the technical engagement: scope, test accounts, environment, and remediation.
  • Olaf Jacobson (ISM) — commissions the test, agrees deliverables, tracks findings to closure, reports to management review.
  • Tester — independent of the people who built the system.

Change log

Version Date Author Comments
0.1 2026-08-13 ISMS First draft, written ahead of the first penetration test — cadence and scope, preconditions (S-299 first), what the tester needs, expected deliverables including a re-test, rules of engagement, monitoring during the test, and remediation to the existing SLAs.