Skip to main content

Separation of Duties Policy

Document control

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

Satisfies ISO/IEC 27001:2022 A.5.3 (segregation of duties) and supports SOC 2 CC3.x (fraud / SoD considerations). Closes Gap 9 of the SSDLC gap analysis. The mechanisms below are already implemented in Supply Chain & CI/CD Security and the Change Management Policy; this policy states them as a single named control.


1. Purpose

No single individual can author, approve, and release a change to production unchecked. Conflicting duties are split across distinct parties so that an error or malicious act on one side is caught on another.

2. Scope

The software development lifecycle: writing code, reviewing and approving it, merging, and deploying to non-production and production.

3. Separated duties (and how each split is enforced)

Duty ADuty BSeparationEnforced by
Write codeApprove codeAuthor may not approve their own PRBranch protection + required CODEOWNER review
Propose changesChange repo / security settingsContractors are Write-only; only the S.E.T team holds AdminGitHub org roles (page 08 access model)
DevelopAccess production / cloudDev firm holds no AWS credentials; only S.E.T controls prodNo-AWS-access model + OIDC
Approve a changeDeploy a changeDeployment is automated via short-lived OIDC after approval — no human deploys with standing credsJob separation + OIDC deploy role
Approve to nonprodPromote to productionA second, deliberate approval is required to reach prod (four-eyes)GitHub "production" Environment required-reviewer gate

All of the above are documented in Supply Chain & CI/CD Security (access model, stage-by-stage controls, core principles).

4. Small-team reality & compensating controls

S.E.T is a small organization, so duties cannot always be divided across many people. Where headcount limits strict separation, these compensating controls apply:

  • Branch-protection and Environment gates cannot be bypassed (with "include administrators" enabled).
  • Automated deployment removes the manual deploy step — releases are performed by the pipeline, not by a person with standing access.
  • Immutable, append-only audit logs record every approval and deployment (who approved which production deploy).
  • Monthly GitHub audit-log review + quarterly access reconciliation detect any concentration of privilege.
  • Production promotion requires two approvers (four-eyes) where staffing allows.

5. Evidence

  • PR approvals showing author ≠ approver
  • GitHub deployment + approval logs (who promoted to prod)
  • CODEOWNERS file + branch-protection / Environment configuration
  • Monthly audit-log review + quarterly reconciliation records

Retained ≥ 12 months per the Change Management Policy and Observability & Logging.

6. Document change history

VersionDateAuthorDescription of changeApproved by
1.02026-05-25Ron Benisty (CTO & CSO)Initial version — states segregation of duties as a named control.Ron Benisty (CTO & CSO)