Topics in this domain
- IT Governance vs. IT Management
- Board and Senior Management Roles
- IT Steering Committee
- IT Strategy and Business Alignment
- Balanced Scorecard
- COBIT
- ITIL
- ISO 27001/27002
- COSO: ERM and Internal Control
- Policies, Standards, Procedures, Guidelines
- IT Organizational Structure and Key Roles
- Segregation of Duties in IT
- Enterprise Architecture (Zachman, TOGAF)
- Risk Management Process
- Qualitative vs. Quantitative Risk Assessment
- Risk Responses: Mitigate, Transfer, Avoid, Accept
- Risk Appetite and Residual Risk
- Maturity Models (CMMI)
- KPIs and KGIs
- Outsourcing: Benefits and Risks
- Vendor Selection, Contracts, SLAs, Right to Audit
- Cloud and Offshore Governance
- Portfolio and Resource Management
- HR: Hiring, Training, Termination
- Legal and Regulatory Compliance
- Quality Management
Segregation of Duties in IT
Why IT needs its own rules
The general principle is covered in Domain 1: no one person should be able to both do something wrong and cover it up. IT adds its own twist, because some IT jobs come with enormous power: changing programs, changing data, granting access. Put two of those powers in one pair of hands, and one person can change anything and erase the evidence.
Think of a bank vault. The person who makes the keys shouldn’t also be the person who opens the vault, and neither should be the person who checks the vault’s contents. In IT, “keys” are access rights, “the vault” is production, and “checking” is reviewing logs.
The dangerous combinations
| Keep apart | Why |
|---|---|
| Development and production operations | Developers could put untested or malicious code live |
| Security administration and any other IT job | The person controlling access shouldn’t benefit from it or be able to hide activity |
| Operations and program changes | Operators could run programs they’ve secretly changed |
| Database administration and security administration for the same data | Unlimited, unwatched access to data |
| Business transactions and IT administration | Application controls could be bypassed |
| Requesting a change and approving it | Changes could be self-approved |
| Quality assurance and development | Testing could be compromised |
Not every combination is a problem. A developer who builds and later maintains the same program is normal, as long as they don’t have production access.
Finding conflicts
- Build or get an IT conflict matrix.
- Pull actual access from production servers, databases, deployment tools, admin consoles and the identity system. Don’t forget service accounts and shared administrator accounts.
- Analyse who holds clashing rights. Automated SoD tools help, especially in ERP systems.
- Observe who really does each task. Shared passwords defeat SoD on paper.
- Fix conflicts, or check that compensating controls cover them.
Small IT team? Compensate
Small IT teams often can’t separate everything. The exam’s expected answer is a compensating control, not hiring:
- independent review of production changes against approved tickets
- logging of privileged activity, reviewed by someone outside IT (such as a finance manager)
- regular access reviews by data owners
- supervisory review of sensitive transactions
Example. In a five-person IT team, one engineer manages both Active Directory and the ERP database. Splitting the role isn’t possible. Each month, the security monitoring system produces a report of all group changes, schema changes and privilege changes, and the finance controller checks each one against an approved request.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Most serious IT SoD conflict | Developer with production access, or security administration combined with other duties |
| Who should not have access to production data? | Developers (and operators shouldn’t change programs) |
| SoD can’t be achieved in a small IT team | Compensating controls: independent review of logs and changes |
| Best evidence of SoD violations | Actual system access compared with a conflict matrix |
In short
- In IT, the key separations are between development, operations, security administration and business users.
- Developers shouldn't access production; operators shouldn't change programs; security administrators shouldn't do business transactions.
- The worst conflicts let one person make an unauthorised change and hide it.
- SoD is checked by comparing actual system access with a conflict matrix, reviewing job descriptions, and observing.
- Where separation isn't possible, compensate with independent review of logs, reconciling changes to approvals, and supervisory review.
- Automated SoD tools and careful role design reduce conflicts in ERP systems.
Exam traps
- A developer maintaining their own code isn't a conflict by itself; production access is.
- Security administration combined with any other IT role is a serious conflict.
- The DBA shouldn't also be the security administrator for the same database.
- End users who can edit production data directly bypass application controls.
- For small IT teams, the exam wants compensating controls, not reorganisation.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The dangerous combinations