DPWAT-ISMS-POL-016 v1.0

Segregation of Duties & Dual Control Policy

Document ID: DPWAT-ISMS-POL-016
Version: 1.0
Owner: ISMS Manager / CISO (RMSI) — Timo Andreas Bejan
Approved by: Administrator (ADM) — Anna Boros
Effective date: 2025-10-15
Next review: 2027-02-01 (or on major change)

1. Purpose

Reduce the risk of errors, misuse of privilege, fraud, and unauthorized changes by separating conflicting duties where feasible, and applying compensating controls where separation is not feasible (due to company size or customer constraints).

2. Scope

This policy applies to all personnel performing DP WAT work (employees and contractors) and to DP WAT-managed systems and customer systems where DP WAT has access.

3. Principles

DP WAT separates duties for security-critical activities where feasible.
Where separation is not feasible, DP WAT applies compensating controls and records the decision via the exception/risk acceptance process.
Evidence is produced through access/change records and periodic reviews (internal audit, access reviews, management review).

4. Common conflicting duties (examples)

DP WAT considers these duties to be potentially conflicting (non-exhaustive):

Access request/approval vs. provisioning: the person receiving access should not be the sole approver of their own privileged access.
Change authoring vs. approval: the author of a high-risk change should not be the sole approver of that change.
Security oversight vs. implementation: a single person should not be able to both define security rules and change them without visibility/approval.

5. Minimum controls (how we implement SoD)

5.1 Access and privileged roles

Access must be requested and approved before provisioning (see 04.02-access-request-changes-and-offboarding).
Privileged access (admin/owner) requires explicit approval and should be limited to named individuals.
Where feasible, privileged role assignments are approved by a different Administrator than the person receiving the privilege.
Where separation is not feasible, record the justification and apply compensating controls (MFA, logging, and periodic access review).

5.2 Changes, releases, and production-impacting actions

Changes follow 04.03-change-management.
High-risk changes require a second-person approval (e.g., pull request approval, ticket approval, or written approval) before merge/deploy.
Emergency changes may be performed by a single person, but require a retrospective review by another Administrator/CISO as soon as feasible.

5.3 Reviews and audits

Segregation of duties effectiveness is checked during internal audit (see 04.09-internal-audit) and management review.

6. Customer-managed environments

DP WAT personnel may have privileged access (including root-equivalent) to customer-managed production environments as required for service delivery. For these environments:

Access is granted by and at the discretion of the customer.
DP WAT records such access in the access register (access-register).
Where full SoD is not feasible (e.g., single DP WAT person with both code and deploy rights), compensating controls include:
Customer oversight and approval of changes
Logging/audit trails maintained by customer infrastructure (e.g., CloudTrail, GitHub audit logs)
MFA on all accounts
Periodic review of access as part of customer engagement reviews
DP WAT will, where feasible, request customers provide named admin roles rather than root/owner credentials.

7. Exceptions and risk acceptance

Where SoD cannot be achieved (e.g., DP WAT static website where both commit and deploy rights exist for the same persons), the exception is:

Documented in the risk register (02.02-risk-register)
Mitigated via compensating controls (logging, retrospective review, MFA)
Reviewed during internal audit and management review