Skip to main content

Audit Testing Scope Policy

Document control

FieldValue
OwnerRon Benisty — CTO & CSO (ron.b@iontwrks.com)
StatusApproved
Version1.0
ClassificationConfidential
Approved byRon Benisty — CTO & CSO
Approval date2026-05-26 (Tuesday)
Last reviewed2026-05-26
Review cycleAnnual — next review due May 2027
Parent policySecure SDLC (SSDLC)

Satisfies ISO/IEC 27001:2022 A.8.34 (protection of information systems during audit testing). Closes the A.8.34 gap referenced in SSDLC §3.


1. Purpose

Scope audit activities — both inbound (someone auditing S.E.T) and outbound (S.E.T exercising its right-to-audit against the third-party dev firm) — so that audit testing produces useful evidence without disrupting production or compromising customer data.

2. Inbound audits (someone auditing S.E.T)

Audit typeScopeAccess grantedRestrictions
SOC 2 Type II (external)Evidence in the Evidence Register over the audit windowRead-only, scoped, time-boundedNo write / delete; no direct DB access; no access to customer audit data unless explicitly required for control testing
ISO/IEC 27001 surveillance audit (external)The full ISMS scope (this SSDLC + ISMS docs as they materialize)Read-only, scopedSame as above
Customer audit under right-to-audit DPA clauseTheir own tenant data + S.E.T's control evidence relevant to themRead-only via tenant export + Q&ATime-bounded, scope agreed in writing
Internal audit / self-assessmentPer the Evidence RegisterCTO & CSO sets scopeDocumented in the §5 record

3. Outbound audit — S.E.T auditing the third-party dev firm

Per the right-to-audit clause in Supply Chain & CI/CD Security §3 contract requirements:

  • Cadence: at least annually, or on incident.
  • Scope: dev-firm collaborator roster vs. our GitHub collaborator list, the firm's 2FA enforcement evidence, their offboarding records for any developer who left during the year, breach-notification history.
  • Form: written request + Q&A or video call; the firm provides documented evidence; no S.E.T access to the firm's internal systems is required.
  • Output: a signed annual review record, retained ≥ 12 months.

4. Coordination rules (apply to every audit activity)

  • Written scope agreement before any active testing begins (≥ 5 business days lead time where practical).
  • No active scanning against prod (DAST, vuln scans, pen tests) without a separately approved engagement (see the Vulnerability Management Policy for ongoing scanner findings, and the DAST & Penetration Testing Policy for periodic engagements).
  • Read-only by default — auditors do not receive write access to any S.E.T system.
  • Time-bounded credentials — any auditor access uses short-lived, scoped credentials (CloudTrail-logged).
  • Blackout windows — production deploys, incident response, and any active outage automatically suspend audit activity.
  • Emergency abort — the CTO & CSO may suspend any audit activity at any time with immediate notice and a written record.

5. Evidence

Every audit activity — inbound or outbound — produces:

  • A signed scope agreement.
  • The auditor's access log (CloudTrail / GitHub audit log for inbound; written record for outbound).
  • The audit report or output document.
  • Any remediation PRs filed as a result (Change Management).

Retained ≥ 12 months per the Evidence Collection & Retention Policy.

6. Document change history

VersionDateAuthorDescription of changeApproved by
1.02026-05-26Ron Benisty (CTO & CSO)Initial version — establishes audit testing scope rules (inbound + outbound).Ron Benisty (CTO & CSO)