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 closed out. Fix the known items first.

# Precondition Why Status
1 ✅ Production database is private — closed 2026-08-19. No public endpoint; engineers connect through SSM Session Manager A tester should be probing the application, not an exposed data store Met
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, confirmed 2026-08-24. GetAgency's testers run against production because the attest firm requires it, and a Work Order is signed before scheduling. Testing production gives the truest result and carries real risk, so §5 exists.
  • 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~~ — not included, and not required. GetAgency confirmed on 2026-08-24 that neither SOC 2 nor ISO 27001 requires a re-test, provided remediation is tracked to completion in a ticketing system. Ours is Linear, so the trail exists.

This is a deliberate acceptance rather than an oversight. A re-test proves the fix; a ticket proves we made it and says so on our own authority. If a finding is severe enough that our word should not be the last word on it, buy a re-test for that finding rather than assuming the engagement covers one. - Confirmation of whether the report can also support ISO/IEC 27001 certification.

Before a production test starts, three things must be true (added 2026-08-24):

  1. A restore has been tested. Nobody should be probing production when we cannot yet demonstrate recovery from it — S-412.
  2. The team has been briefed. GuardDuty, Sentry and CloudWatch will fire during the window. An alert treated as a real incident wastes a day; an alert ignored as "probably the pen test" is worse, which is why the tester's source IPs are agreed in advance.
  3. The Work Order is signed, and the window is scheduled rather than open-ended.

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. Track every finding to closure in Linear — one issue per finding, closed only when the fix is deployed and verified. That trail is what stands in place of a re-test, so it has to be real.
  5. Feed material findings into the risk register and raise them at the next management review.
  6. Index the report and the closed remediation tickets 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.2 2026-08-25 ISMS Aligned with GetAgency's actual engagement: greybox against production under a signed Work Order, and no re-test — they confirmed neither SOC 2 nor ISO requires one where remediation is tracked to closure in a ticket system. Recorded as a deliberate acceptance, with the note that a severe finding may still warrant buying a re-test rather than relying on our own word. Added the three preconditions a production test needs: a proven restore, a briefed team with agreed tester IPs, and a scheduled window.
0.1 2026-08-13 ISMS First draft, written ahead of the first penetration test — cadence and scope, preconditions, what the tester needs, expected deliverables including a re-test, rules of engagement, monitoring during the test, and remediation to the existing SLAs.