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
IT Organizational Structure and Key Roles
Why the org chart matters
How IT is organised decides who can do what. A good structure:
- keeps incompatible jobs apart (segregation of duties)
- makes it clear who’s accountable for each area
- keeps the people who check work (security, QA) independent of the people who do it
Think of a restaurant. The chef cooks, the health inspector checks the kitchen, and the cashier handles money. If the chef also inspected their own kitchen and kept the till, problems could go unnoticed for a long time.
The roles
| Role | Should | Shouldn’t |
|---|---|---|
| CIO / IT director | Lead IT, align it with the business, manage resources | Make major investment decisions alone, without business input |
| Developer / systems analyst | Gather requirements, design, build and maintain applications in development | Have access to production programs or data |
| Quality assurance | Check standards are followed and changes are tested | Report to the development manager whose work they check |
| IT operations | Run production systems, schedule jobs, monitor, handle backups | Change programs or jobs without approval |
| Database administrator (DBA) | Maintain database structures, performance, backup and recovery | Approve data changes, grant their own access, or work unlogged |
| Systems administrator | Maintain servers and operating systems | Review their own activity logs |
| Network administrator | Maintain network devices and connectivity | Change firewall rules outside change control |
| Security administrator | Set up access as approved, manage user IDs, monitor violations | Report to operations or development; do business transactions |
| Service desk | Be the single point of contact; log and route incidents and requests | Grant access without approval |
| Data owner (business) | Classify data, approve access, accept residual risk | Leave access decisions to IT |
| Data custodian (often IT) | Store, back up and protect data as the owner directs | Decide who should have access |
Independence of the checkers
Two placement points come up often:
- Security administration should be independent of operations and development. If it reports to the head of operations, the people being controlled can influence the controls.
- Quality assurance must be independent of development. QA under the development manager may be pressured to pass changes that aren’t ready.
Powerful roles need watching
DBAs, system administrators and network administrators have privileged access that can bypass application controls. The answer isn’t to get rid of them; it’s to limit and watch them:
- least privilege and named (not shared) accounts
- logging of privileged activity, reviewed by someone independent
- privileged access management tools, such as a password vault and time-limited access
Paper vs practice
Example. The org chart shows security administration reporting to the CISO. In practice, the operations manager approves every access request and the security administrator just types them in. The auditor reports that real practice doesn’t match the intended structure, and that data owners aren’t approving access.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Where security administration should report | Independently of operations and development (such as to the CISO) |
| Main concern with DBA access | Changing data directly, bypassing application controls |
| Who approves access to data? | The data owner |
| QA reports to the development manager | Independence is compromised |
| Best control over privileged administrators | Logging with independent review |
In short
- The IT structure should support segregation of duties and clear accountability.
- Key roles: CIO, developers, quality assurance, IT operations, database administrators, systems and network administrators, security administrators, service desk.
- Security administration should be independent of IT operations and development, often reporting to the CISO.
- Quality assurance must be independent of the developers whose work it checks.
- DBAs and system administrators have powerful access; their activity should be logged and reviewed by someone independent.
- Business data owners decide on access; IT acts as custodian.
Exam traps
- Security administration reporting to the head of development or operations weakens independence.
- QA reporting to the development manager isn't independent.
- A DBA approving data changes or granting their own access is a conflict.
- An organisation chart shows the intended structure; the auditor checks what really happens.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Why the org chart matters
How IT is organised decides who can do what. A good structure keeps incompatible jobs apart, makes it clear who's accountable, and keeps the people who check work independent of the people who do it.
1 / 9