ctrls.report
Worked example · v1
Worked example · one control, end to end

Segregation of duties, audited from start to finish

The whole audit of one control, laid out plainly: a developer must not be able to build a change and release it to production without independent approval. Follow the flow, use the tool named at each step.

The method, in one line

Re-perform the conflict analysis yourself — pull the access data and flag the toxic combinations — then prove the control technically enforces the separation. Source-code review only where it's enforced in custom code.

ISO/IEC 27001 · A.5.3 — NIST 800-53 · AC-5 — Cloud: AWS / Azure / GCP
01

How the audit runs

Nine stages in three phases. Each card says what you do and which part of the pack you use — expand a step for what a pass and an exception look like.

Plan & understand

1

Plan & scope

Conflict matrix (SOD-1)

Define the control, the conflicting duties in scope, the systems and pipelines involved, and the audit period.

2

Understand the process

Interview guide

Interview the control owner, IAM admin and DevOps lead; walk one change from a developer's commit all the way to production.

3

Assess control design

Judgement

Decide whether the process, as designed, actually stops one person from holding conflicting duties.

Test

4

Obtain the population

Test programme · SOD-2

Export who can develop, who can approve and who can deploy — plus the list of production deployments for the period.

5

Re-performance

Re-performance (SOD-3)

Map every user to their capabilities and flag anyone holding a conflicting combination. Your independent re-run — don't rely on the client's own analysis.

What pass vs exception looks like
Pass — no user holds a conflicting combination. Exception — a user can both create and release a change without independent approval.
6

Functionality validation

Test programme · SOD-4

Prove the control enforces it: approval gate required and non-self-approvable, branch protection on, deploy restricted to a separate role.

What pass vs exception looks like
Source-code review is the fallback Only where the separation is enforced in custom code rather than platform config.
Pass — gate enforced and cannot be self-approved. Exception — gate optional, bypassable, or self-approvable.

Conclude & report

7

Evaluate exceptions

Findings

For each conflict found, check whether an independent detective review catches it, and judge the residual risk.

8

Document & conclude

Evidence log + Findings

Reference every piece of evidence, record the result of each step, and conclude on whether SoD operated effectively.

9

Report

Findings & conclusion

Summarise the findings, the risk and the recommendations for the report.

02

The conflict matrix

The heart of the test. Any single person holding two capabilities marked Conflict breaches segregation of duties. This is what step 1 defines and step 5 checks against.

C1 Develop / commit  ·  C2 Review / approve  ·  C3 Deploy to prod  ·  C4 Manage access  ·  C5 Modify pipeline

C1
C2
C3
C4
C5
C1 Develop / commit
Conflict
Conflict
Conflict
Conflict
C2 Review / approve
Conflict
Monitor
Conflict
Conflict
C3 Deploy to prod
Conflict
Monitor
Conflict
Conflict
C4 Manage access
Conflict
Conflict
Conflict
Conflict
C5 Modify pipeline
Conflict
Conflict
Conflict
Conflict
Conflict — never one person
Monitor — only if approval is independent
Same duty
Develop + DeployConflictAuthor could release their own change to production unchecked.
Develop + ApproveConflictAuthor would approve their own change — independent review is lost.
Approve + DeployMonitorAcceptable only where approval is genuinely independent; watch for self-approval.
Manage access + Modify pipelineConflictWould control both who has access and the pipeline that enforces the gate.
03

What good evidence looks like

Step 8 lives or dies on evidence quality. Whatever you capture, hold it to four tests.

01
Timestamped

Record the capture date and time in UTC — and get the on-screen clock into the screenshot where you can.

02
Source-attributable

Note which system and account it came from, and which export or query produced it.

03
Complete for the period

A single point-in-time snapshot won't survive a review that covers a whole period.

04
Unaltered

Keep the raw export. Note any redaction. Reference every item to the step it supports.

What's in the pack

The walkthrough above maps onto eight working tabs — the fillable tools you actually run the audit in.

1 · ProcessThe end-to-end flow, with a diagram alongside the narrative.
2 · InterviewsWho to speak to and exactly what to ask.
3 · Test programmeThe steps: what to look at, where in each cloud, and how.
4 · Evidence logCapture screenshots and evidence with timestamps.
SOD-1 · Conflict matrixThe conflicting-duty grid, ready to adapt.
SOD-3 · Re-performanceMap users to capabilities and flag the conflicts.
FindingsExceptions, risk, recommendations and the conclusion.
Read meHow the whole pack fits together.