Domain 2: Governance and Management of IT
Arrow keys or space to move, F for full screen. Read the notes
Governance and Management of IT
26 topics · Governance · Organization and policy · Risk · Management
D2IT Governance vs. IT Management
The difference between steering (governance) and rowing (management), what IT governance tries to achieve, and how to spot which one a question is about.
Steering and rowing
Picture a boat. Someone decides where it should go and keeps checking it's on course: that's governance. The crew rows, manages the sails and fixes leaks: that's management.
Both matter. A brilliant crew rowing in the wrong direction gets nowhere useful, and a perfect course is useless if nobody rows.
Governance vs management
Who sits where
| Body | Level | Role |
|---|---|---|
| Board of directors | Governance | Accountable; sets direction and risk appetite |
| IT strategy committee | Governance (board level) | Advises the board on IT strategy |
| Audit committee | Governance | Oversees audit, risk and control |
| IT steering committee | Management | Prioritises projects, monitors delivery |
| CIO and IT management | Management | Runs IT |
What IT governance tries to get right
Smooth IT, missing governance
IT runs smoothly and projects finish on time. But the board hasn't discussed IT since approving a budget three years ago, and the CIO alone decides what to invest in.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who is ultimately accountable for IT governance | The board |
| Which activity is governance, not management | Setting direction, approving strategy and appetite, monitoring |
| Main objective of IT governance | Align IT with business goals and deliver value |
| Best sign of effective IT governance | Board and senior management involved in IT direction |
| Which body advises the board on IT strategy | IT strategy committee |
Key takeaways
- ✓Governance evaluates options, sets direction and monitors results (EDM). It's the board's job.
- ✓Management plans, builds, runs and monitors activities within that direction (PBRM). It's executive management's job.
- ✓IT governance is part of corporate governance, not something IT does on its own.
- ✓IT governance focuses on strategic alignment, value delivery, risk management, resource management and performance measurement.
- ✓Governance asks 'are we doing the right things?'; management asks 'are we doing things right?'.
- ✓IT running smoothly day to day doesn't prove IT governance is good.
Exam traps
- !Setting direction and monitoring = governance. Planning and running = management.
- !The CIO is a manager. Accountability for IT governance sits with the board.
- !The IT steering committee supports governance but is a management-level body.
- !Good operations don't prove good governance; ask whether the board is involved in IT direction.
Board and Senior Management Roles
Who's responsible for what in IT governance, from the board down to the data owner, and why 'senior management support' is so often the right answer.
Who's in charge of what?
Good governance needs clear answers to 'whose job is this?'. Otherwise everyone assumes someone else is handling it.
The exam tests these roles constantly, usually by describing a decision and asking who should make it.
The board
The board is accountable for the organisation's governance, including IT and security. It can hand activities to committees and managers, but it can't hand away the accountability.
Senior management
Executive management, led by the CEO, turns the board's direction into action. Crucially, management is responsible for internal controls; internal audit only checks them.
Tone at the top
When the exam asks for the MOST important factor in making a governance, risk or security program succeed, the answer is very often senior management commitment and support. Without it, policies have no authority and programs have no money.
Other key roles
| Role | Responsibility |
|---|---|
| CIO | Leads IT; aligns it with the business; manages IT resources |
| CISO | Leads the information security program |
| Process owner | Owns a business process and its controls |
| Data owner | Classifies data, approves access, accepts risk for it |
| Data custodian (often IT) | Stores and protects data as the owner directs |
| Users | Follow policy; use systems as authorised |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who is responsible for setting up internal controls | Management |
| Who sets risk appetite | The board |
| Most important factor in a governance or security program | Senior management commitment and support |
| Who approves access to data | The data owner |
| Role of the audit committee | Oversight of audit and internal control |
Key takeaways
- ✓The board is accountable for governance, including IT and information security, and sets the risk appetite.
- ✓Senior management carries out the board's direction and is responsible for setting up and maintaining internal controls.
- ✓The IT strategy committee advises the board on IT strategy; the IT steering committee oversees delivery at management level.
- ✓The audit committee oversees internal audit, external audit, financial reporting and the control environment.
- ✓Business data owners decide on data classification and access; IT acts as custodian.
- ✓'Tone at the top' (visible senior management support) is the most important factor for governance and security programs.
Exam traps
- !Responsibility for internal controls lies with management, not internal audit.
- !The board can delegate activities but not accountability.
- !The CISO doesn't own business data; data owners do.
- !'Most important factor for success' questions usually point to senior management support.
IT Steering Committee
The group that decides which IT projects go ahead and keeps them on track: who should be on it, what it does, how it differs from the IT strategy committee, and what the auditor checks.
Who decides which projects go ahead?
Every department wants something from IT: a new CRM, a faster website, a payroll upgrade. There's never enough money or people for all of it.
The IT steering committee is where business leaders and IT decide together which projects get done, and then keep an eye on them.
Strategy committee vs steering committee
What the steering committee does
Who should be on it
Senior people from the business units that depend on IT, plus the CIO and key advisers such as security, architecture and finance, often chaired by a sponsoring executive. Business representation is the whole point.
What the auditor checks
- 1 Charter Written purpose, authority and membership.
- 2 Members Senior business people, not just IT.
- 3 Meetings Held regularly; minutes kept.
- 4 Decisions Traceable to business strategy.
- 5 Follow-through Actions tracked; projects monitored.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main job of the IT steering committee | Prioritise and oversee IT projects in line with the business |
| Best evidence the committee works | Minutes showing decisions and follow-up |
| Weakness in membership | No senior business representatives |
| How it differs from the IT strategy committee | Steering = management, delivery; strategy = board, advisory |
Key takeaways
- ✓The IT steering committee is a management-level group that prioritises IT investments and oversees major projects and resources.
- ✓It includes senior business representatives, not just IT, so decisions reflect business priorities.
- ✓The IT strategy committee works at board level and advises on strategy; the steering committee works at management level on delivery.
- ✓It should have a written charter setting out its responsibilities, authority and members.
- ✓Minutes and recorded decisions are the best evidence it actually works.
Exam traps
- !A steering committee of only IT managers can't make sure IT matches business priorities.
- !The steering committee oversees and decides; it doesn't do detailed project management.
- !A charter alone doesn't prove the committee works; minutes do.
- !Strategy committee = board, advisory. Steering committee = management, delivery.
IT Strategy and Business Alignment
Why IT strategy must grow out of business strategy, the difference between long-term and yearly IT plans, and how an auditor checks that they actually line up.
Why alignment matters
IT exists to help the business do what it's trying to do. A beautifully run IT department building things the business doesn't need is wasting money.
IT strategic planning makes sure IT is heading the same way as the business. When the exam asks what IT strategic planning is mainly for, the answer is alignment.
From business goals to IT projects
Long-term vs yearly plans
| Strategic (long-term) | Operational (yearly) | |
|---|---|---|
| Looks ahead | Three to five years | One year |
| Contains | Direction, target architecture, major initiatives, sourcing | Projects, budgets, staffing, targets |
| Approved by | Senior management or the board | IT management with the steering committee |
| Reviewed | Regularly and when business strategy changes | Yearly, tracked through the year |
Signs of good alignment
How the auditor checks it
- 1 Business strategy Start here, always.
- 2 IT strategy Written, approved, current?
- 3 Map initiatives Each one to a business goal.
- 4 Check the budget Does spending follow the strategy?
- 5 Check measurement Are benefits tracked?
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main goal of IT strategic planning | Align IT with business goals |
| First document to review | The business strategy or business plan |
| Best evidence of alignment | IT projects and budgets traceable to business goals, with business involvement |
| Who approves the IT strategic plan | Senior management or the board |
| Business strategy changed a lot | Review and update the IT strategy |
Key takeaways
- ✓IT strategy should come from, and support, the business strategy. Alignment is the main goal of IT strategic planning.
- ✓Strategic (long-term) IT plans cover three to five years; operational (short-term) plans turn them into this year's projects and budgets.
- ✓Strategic plans are approved by senior management or the board and reviewed regularly, especially when business strategy changes.
- ✓The auditor starts with the business strategy, then checks IT plans, projects and budgets trace back to it.
- ✓Business involvement (sponsors, steering committee) is key evidence of alignment.
- ✓A strategy that exists only in IT, or isn't reflected in budgets and projects, isn't working.
Exam traps
- !The first document to review when assessing IT strategy is the BUSINESS strategy.
- !An IT plan focused on technology refresh with no link to business goals shows poor alignment.
- !This year's projects that don't follow from the strategic plan mean the strategy isn't being implemented.
- !The CIO alone doesn't approve the IT strategy; senior management or the board does.
Balanced Scorecard
Measuring IT from four angles instead of just the budget, and why the board needs more than money figures to judge how IT is doing.
Why money isn't enough
If you only judged a football team by last season's prize money, you'd miss that its best players are leaving and its training is falling apart. Next season will be a disaster, and the money figures won't warn you.
Budget figures are like that: they show what already happened. A balanced scorecard adds measures that show what's coming.
Four views of IT performance
Example measures
| Perspective | Example measures |
|---|---|
| Business contribution | IT cost as a share of revenue; benefits delivered by projects |
| User orientation | User satisfaction; SLAs met; incident fix times |
| Operational excellence | Availability; change success rate; projects on time and budget |
| Future orientation | Training hours; skills coverage; innovation ideas in progress |
Before you build one
A scorecard measures progress against a strategy. If there's no agreed strategy with clear goals, there's nothing to measure against.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Purpose of an IT balanced scorecard | Measure IT performance and its contribution to the business |
| What's needed before building one | An agreed strategy and goals |
| Perspective about skills and innovation | Future orientation |
| Weakness of judging IT only on budget | Backward-looking, one-dimensional |
Key takeaways
- ✓A balanced scorecard measures performance from several perspectives, not just money.
- ✓The IT balanced scorecard usually has four: business contribution, user orientation, operational excellence and future orientation.
- ✓In IT governance, it's a tool for measuring and reporting how well IT is performing and contributing to business goals.
- ✓Good scorecards mix lagging measures (results) with leading measures (what drives future results).
- ✓You need an agreed strategy first; the scorecard measures progress against it.
Exam traps
- !The scorecard is a performance measurement tool, not a risk assessment or project planning technique.
- !A scorecard with only financial or only technical measures isn't balanced.
- !Before building a scorecard, the strategy and goals it measures must be defined.
COBIT
ISACA's framework for governing and managing IT: the five domains and what lives in each, the components of a governance system, and how auditors use COBIT as a yardstick.
What COBIT is
COBIT is ISACA's framework for governing and managing IT. Think of it as a very complete checklist of everything an organisation should have in place to run IT well, organised so that it maps to other standards like ITIL and ISO 27001.
For auditors, it's a ready-made source of criteria: 'here's what good looks like'.
Five domains, and what lives where
More than processes
COBIT says a governance system is built from seven kinds of components. Processes alone aren't enough: without the right culture, skills and structures, the best-written process gets ignored.
Tailoring and the goals cascade
Capability levels
Each process can be rated from 0 (incomplete) to 5 (optimising), on a scale based on CMMI. The organisation sets a target level for each one; not everything needs level 5.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Which COBIT domain is governance | EDM |
| Where change management sits | BAI |
| Where incidents and continuity sit | DSS |
| Where monitoring of internal control sits | MEA |
| Main use of COBIT for an IS auditor | A source of criteria for governance and management |
Key takeaways
- ✓COBIT is ISACA's framework for the governance and management of enterprise information and technology.
- ✓It separates governance (the EDM domain) from management (APO, BAI, DSS and MEA).
- ✓COBIT 2019 has 40 governance and management objectives in those five domains.
- ✓A governance system is built from components: processes, structures, policies, information, culture, people and technology.
- ✓Design factors (strategy, risk profile, size, threat landscape and so on) tailor COBIT to each organisation.
- ✓Process capability is rated 0 to 5 on a CMMI-based scale; organisations set a target level for each process.
- ✓Auditors use COBIT objectives as criteria for judging governance and management practices.
Exam traps
- !EDM is governance. APO, BAI, DSS and MEA are management.
- !COBIT is a governance framework, not a security standard or a service management manual; it maps to those.
- !MEA is management's monitoring; EDM includes the board's monitoring. Don't mix them.
- !Don't memorise all 40 objectives. Know the five domains and what sits in each.
ITIL
The best-known guide to running IT as a set of services: where it fits next to COBIT and ISO 20000, and the practices (incident, problem, change and others) that keep turning up on the exam.
IT as a service
Users don't care about servers and networks. They care that email works, payroll runs and the website is up. IT service management treats IT as a set of services, each with an agreed level of quality.
ITIL is the most widely used guide to doing that well.
Where ITIL fits
Practices the exam uses
How the practices connect
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Framework focused on IT service management | ITIL |
| Certifiable service management standard | ISO/IEC 20000 |
| Main goal of incident management | Restore service as quickly as possible |
| Main goal of problem management | Find and remove root causes |
| Single point of contact for users | Service desk |
Key takeaways
- ✓ITIL is good-practice guidance for IT service management: running IT as services that deliver value to users.
- ✓COBIT says what to govern and manage; ITIL gives the detailed how for service management.
- ✓ISO/IEC 20000 is the certifiable service management standard; organisations can't be certified to ITIL.
- ✓Practices the exam uses most: service desk, incident, problem, change, service level, configuration and release management.
- ✓Incident management restores service fast; problem management finds and removes root causes.
- ✓The service desk is the single point of contact for users.
Exam traps
- !ITIL isn't a governance framework; COBIT is.
- !Organisations get certified to ISO 20000, not to ITIL.
- !Incident management's goal is fast restoration, not root cause.
- !A workaround keeps things going; the permanent fix goes through change management.
ISO 27001/27002
The international standards for running information security: what an ISMS is, the difference between 27001 and 27002, the Statement of Applicability, and what a certificate does (and doesn't) prove.
A system for managing security
Buying a firewall doesn't make you secure. Security needs to be managed: risks assessed, controls chosen, people trained, results checked, and improvements made, over and over.
ISO/IEC 27001 describes how to run that management system, called an ISMS (information security management system).
27001 vs 27002
How an ISMS works
The Statement of Applicability
Annex A lists reference controls, but organisations pick the ones their risk assessment says they need. The Statement of Applicability records every Annex A control with three answers.
What a certificate proves
Certification means the ISMS met 27001's requirements, for the certified scope, when the certification body last checked. Before relying on it, the auditor asks three questions.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Standard organisations are certified against | ISO/IEC 27001 |
| Purpose of ISO/IEC 27002 | Guidance on implementing security controls |
| Document listing applicable controls and reasons | Statement of Applicability |
| What drives which controls are chosen | Risk assessment |
| First thing to check about a certificate | Its scope |
Key takeaways
- ✓ISO/IEC 27001 sets out the requirements for an information security management system (ISMS). Organisations can be certified against it.
- ✓ISO/IEC 27002 is guidance on how to implement security controls. It isn't certifiable.
- ✓Annex A of 27001 lists reference controls (93 in the 2022 version, in four themes: organisational, people, physical, technological).
- ✓The Statement of Applicability (SoA) records which Annex A controls apply, whether they're in place, and why any are excluded.
- ✓An ISMS follows Plan-Do-Check-Act: risk assessment drives the choice of controls; internal audits and management reviews drive improvement.
- ✓A certificate shows the ISMS meets 27001 for its certified scope. Always check the scope covers what you care about.
Exam traps
- !You get certified to 27001, not 27002.
- !Certification doesn't mean every control works; it means the management system meets the standard for its scope.
- !Controls are chosen by risk assessment, not by implementing all of Annex A.
- !Every exclusion in the SoA needs a justification.
- !A certified data centre doesn't cover the company's software development, unless that's in scope.
COSO: ERM and Internal Control
The most widely used definition of internal control: its five components, why the control environment comes first, and how COSO's risk framework differs.
What internal control means
COSO defines internal control as a process, run by the board, management and staff, that gives reasonable assurance an organisation will achieve its goals for operations, reporting and compliance.
Note 'reasonable'. Controls can be overridden, people make mistakes, and some controls cost more than they're worth. No system of control is perfect.
Five components
Why the foundation matters
If leaders ignore the rules, the best-written controls fail.
Three kinds of objectives
COSO ERM
COSO also publishes a separate enterprise risk management framework. Its big idea: consider risk when SETTING strategy, not just when carrying it out.
| ERM component | Focus |
|---|---|
| Governance and culture | Board oversight, culture, values |
| Strategy and objective-setting | Risk appetite; strategy chosen with risk in mind |
| Performance | Identify, assess, prioritise and respond to risks |
| Review and revision | Adapt as things change |
| Information, communication, reporting | Risk information shared for decisions |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Foundation of internal control in COSO | Control environment |
| Component that includes IT general controls | Control activities |
| Level of assurance internal control gives | Reasonable, not absolute |
| Framework used for SOX reporting | COSO Internal Control - Integrated Framework |
| Framework linking risk to strategy | COSO ERM |
Key takeaways
- ✓COSO's Internal Control framework has five components: control environment, risk assessment, control activities, information and communication, and monitoring activities (with 17 principles).
- ✓The control environment (integrity, ethics, tone at the top) is the foundation for everything else.
- ✓Internal control gives reasonable, not absolute, assurance about operations, reporting and compliance.
- ✓IT general controls fall under the control activities component.
- ✓COSO ERM (2017) is a separate framework that links risk to strategy and performance.
- ✓COSO is the framework most US companies use for Sarbanes-Oxley internal control reporting.
Exam traps
- !The control environment is the foundation; control activities are just one of five components.
- !Internal control gives REASONABLE assurance, never absolute.
- !Monitoring in COSO means ongoing and separate evaluations, including internal audit.
- !COSO Internal Control and COSO ERM are different frameworks with different purposes.
Policies, Standards, Procedures, Guidelines
The four kinds of governance document, from broad intent to step-by-step instructions, who approves each, and how an auditor tells whether they actually work.
From 'why' to 'how'
Organisations write down how things should be done at four levels of detail. The higher the level, the shorter and more stable the document; the lower the level, the more specific and the more often it changes.
An everyday example
Who approves what
| Document | Mandatory? | Typical approver / owner |
|---|---|---|
| Policy | Yes | Senior management or board |
| Standard | Yes | Function head (CISO, CIO) |
| Procedure | Yes | Process owner |
| Guideline | No | Subject expert |
Top-down vs bottom-up
Making policies work
- 1 Approve By the right level.
- 2 Communicate Staff receive it and acknowledge it.
- 3 Enforce Technical controls and consequences.
- 4 Handle exceptions Approved, risk-assessed, time-limited.
- 5 Review Regularly and after big changes.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who approves the information security policy | Senior management (or the board) |
| Which document isn't mandatory | Guideline |
| Benefit of top-down development | Alignment with business goals and consistency |
| Policy exists but staff don't know it | Ineffective; communication and awareness needed |
| Document setting minimum password length | Standard |
Key takeaways
- ✓Policies state management's intent; standards set mandatory specifics; procedures give step-by-step instructions; guidelines offer advice.
- ✓Policies, standards and procedures are mandatory. Guidelines aren't.
- ✓Policies are approved by senior management or the board; procedures are owned by process owners.
- ✓Top-down development starts from business goals; bottom-up starts from risks in existing systems. Top-down ensures alignment.
- ✓Policies must be communicated, acknowledged, enforced, and reviewed regularly.
- ✓Lower-level documents must support the higher ones, with no contradictions.
Exam traps
- !A policy that exists but isn't communicated or enforced is ineffective.
- !Guidelines are optional; standards and procedures are mandatory.
- !Policies don't name products or settings. That's a standard.
- !The security policy is often the first document an auditor reviews in a security audit.
- !Exceptions to policy must be formally approved, risk-assessed and time-limited.
IT Organizational Structure and Key Roles
The IT jobs the exam expects you to know, what each one should and shouldn't do, and why where a role reports matters as much as what it does.
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.
Each role's do's and don'ts
| Role | Should | Shouldn't |
|---|---|---|
| Developer | Build and maintain applications in development | Have access to production |
| Quality assurance | Check standards and testing | Report to the development manager |
| IT operations | Run production systems and approved jobs | Change programs without approval |
| Database administrator | Maintain databases, performance, backups | Approve data changes or grant own access |
| Security administrator | Set up access as approved; monitor violations | Report to operations; do business transactions |
| Data owner (business) | Classify data; approve access | Leave access decisions to IT |
Independence of the checkers
Powerful roles need watching
DBAs, system administrators and network administrators can bypass application controls. The answer isn't to remove them; it's to limit and watch them.
- 1 Least privilege Only the rights the job needs.
- 2 Named accounts No shared admin logins.
- 3 Log everything Privileged actions recorded.
- 4 Independent review Someone else reads the logs.
Paper vs practice
The org chart shows security administration under the CISO. In practice, the operations manager approves all access requests and the security administrator just types them in.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Where security administration should report | Independently of operations and development (e.g. 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 |
Key takeaways
- ✓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.
Segregation of Duties in IT
The IT-specific jobs that should never sit with one person, how to find conflicts in real system access, and what to do in a small IT team.
Why IT needs its own SoD rules
The general idea is simple: 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 a single person can change anything and erase the evidence.
The dangerous combinations
Finding conflicts
- 1 Conflict matrix Which IT roles and rights clash.
- 2 Pull real access Servers, databases, deployment tools, admin consoles, service accounts.
- 3 Analyse Who holds clashing rights? Tools help in ERP.
- 4 Observe Shared admin passwords defeat SoD on paper.
- 5 Fix or cover Remove conflicts, or check compensating controls.
Small IT team? Compensate
A five-person IT team can't split every job. The exam's expected answer is a compensating control, not hiring.
In practice
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… | Answer |
|---|---|
| Most serious IT SoD conflict | Developer with production access, or security admin plus other duties |
| Who shouldn't have access to production data | Developers |
| SoD not possible 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 |
Key takeaways
- ✓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.
Enterprise Architecture (Zachman, TOGAF)
A map of the organisation's processes, data, applications and technology, used to steer IT investment. Plus the two frameworks the exam names.
A map of the organisation
Imagine a city with no planning office. Everyone builds wherever they like: three hospitals on one street, no roads between neighbourhoods, pipes that don't connect.
Enterprise architecture is IT's planning office. It maps what exists, decides what the city should look like, and checks every new building fits the plan.
Current state to target state
Four layers to map
Zachman and TOGAF
Why it pays off
Three departments each buy their own CRM tool without telling IT. An architecture review, checking new systems against the target architecture, would have spotted the duplication and the integration cost before anyone signed a contract.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main purpose of enterprise architecture | Align IT investment with strategy; manage complexity |
| Framework that is a classification grid | Zachman |
| Framework with a development method (ADM) | TOGAF |
| Best evidence EA is effective | Projects assessed against it before approval |
Key takeaways
- ✓Enterprise architecture (EA) documents how the organisation's processes, information, applications and technology fit together, to guide change.
- ✓It describes the current state, the target state, the gaps, and a roadmap between them.
- ✓Zachman is a grid for classifying architecture descriptions: questions (what, how, where, who, when, why) against viewpoints.
- ✓TOGAF provides a method, the Architecture Development Method (ADM), for building and governing architecture.
- ✓EA supports alignment, reduces duplication and complexity, and gives a basis for judging new investments.
- ✓The auditor checks EA exists, is kept current, and that projects are actually checked against it.
Exam traps
- !Zachman is a classification grid, not a process. TOGAF's ADM is the process.
- !An EA nobody uses in investment decisions has little value.
- !TOGAF's four domains are business, data, application and technology.
Risk Management Process
How organisations find, rank and deal with IT risks, step by step, who owns each part, and the 'what comes first?' questions the exam loves.
What risk actually is
'Risk' gets used loosely. In risk management it has a precise shape: something valuable, something that could harm it, and a weakness that would let the harm happen.
Take away any one of those and the risk shrinks. That's what controls do.
The risk management cycle
Inherent and residual risk
Who does what
| Role | Responsibility |
|---|---|
| Board | Sets risk appetite; oversees |
| Risk owner (business) | Accountable for the risk; decides treatment; accepts what's left |
| Risk function | Framework, methods, facilitation, reporting |
| Control owner | Runs the controls that treat the risk |
| Internal audit | Independent assurance over the whole process |
Keep it current
Risks change with new systems, threats, suppliers and laws. Reassess regularly AND after significant change. Key risk indicators give early warning in between.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step in a risk assessment | Identify and value assets |
| Who accepts residual risk | The business risk owner / senior management |
| What risk is made of | Threats, vulnerabilities and impact on assets |
| When to reassess risk | Regularly and after significant change |
| Internal audit's role | Independent assurance over the process |
Key takeaways
- ✓Risk management starts with context and assets, then threats and vulnerabilities, then analysing likelihood and impact.
- ✓Risk exists when a threat can exploit a vulnerability to harm an asset.
- ✓Risk evaluation compares each risk with the organisation's appetite to decide what to do.
- ✓Treatment options are mitigate, transfer, avoid or accept; residual risk must be within appetite and accepted by the risk owner.
- ✓Risk management is continuous: risks are monitored and reassessed, especially after changes.
- ✓Business risk owners are accountable for their risks; the risk function facilitates; internal audit gives independent assurance.
- ✓A risk register records each risk, its owner, rating, treatment and status.
Exam traps
- !The first step in a risk assessment is identifying and valuing assets, not picking controls.
- !A vulnerability no threat can exploit (or a threat with nothing to exploit) doesn't create much risk.
- !IT doesn't own business risks. The business owner accepts residual risk.
- !An annual risk assessment isn't enough after a big change; reassess when things change.
- !Audit evaluates the risk management process; it doesn't run it.
Qualitative vs. Quantitative Risk Assessment
Two ways to size up a risk: descriptive ratings like high, medium and low, or money and probabilities. Includes the ALE formulas, worked through with real numbers.
Two ways to size a risk
Ask two people how worried to be about a house fire. One says 'low chance, terrible if it happens'. The other says 'about a 0.3% chance a year, costing about 300,000 if it does'.
The first is a qualitative assessment. The second is quantitative. Both are useful, for different jobs.
Qualitative
Likelihood and impact are rated on simple scales and often shown as a heat map. Quick, easy to explain, and fine when there's little hard data. The catch: the ratings are judgement calls.
Quantitative, step by step
Is the control worth it?
A data loss prevention tool costs 40,000 a year. It would cut breaches from once every 5 years to once every 20 (ARO 0.2 → 0.05).
Choosing an approach
| Qualitative | Semi-quantitative | Quantitative | |
|---|---|---|---|
| Scale | High / medium / low | Scores like 1-5 | Money and probabilities |
| Speed | Fast | Moderate | Slow |
| Data needed | Expert judgement | Judgement with scoring | Historical and financial data |
| Good for | Ranking many risks | Consistent ranking | Cost-benefit of controls |
| Weakness | Subjective | Looks more precise than it is | Data hard to get |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Formula for ALE | SLE × ARO |
| Formula for SLE | Asset value × exposure factor |
| Main advantage of quantitative analysis | Supports cost-benefit analysis |
| Main disadvantage of quantitative analysis | Reliable data is hard to get |
| Main disadvantage of qualitative analysis | Subjectivity |
| When a control is cost-justified | ALE reduction exceeds its yearly cost |
Key takeaways
- ✓Qualitative analysis rates likelihood and impact on scales like high, medium and low. Quick and common, but subjective.
- ✓Quantitative analysis uses money and probabilities. It supports cost-benefit decisions but needs reliable data.
- ✓Single loss expectancy: SLE = asset value × exposure factor.
- ✓Annualised loss expectancy: ALE = SLE × annualised rate of occurrence (ARO).
- ✓A control is worth it when the drop in ALE is bigger than the control's yearly cost.
- ✓Semi-quantitative analysis puts numbers on qualitative scales for ranking, without real money values.
Exam traps
- !Exposure factor is the share of the asset's value lost in ONE event, not a probability.
- !ARO is how often per year: 0.1 means once in ten years.
- !Quantitative results look precise but are only as good as the estimates behind them.
- !Qualitative isn't wrong; it's the normal approach when data is scarce.
Risk Responses: Mitigate, Transfer, Avoid, Accept
The four things you can do about a risk, when each makes sense, who gets to decide, and the exam's favourite misunderstandings about insurance and acceptance.
Four ways to respond
Once a risk is assessed, there are only four basic responses. A riverside warehouse at risk of flooding shows them clearly.
What transfer does and doesn't do
Insurance and contracts move the money. They don't move the responsibility.
| Transfers | Stays with you |
|---|---|
| Financial loss covered by the policy or contract | Accountability for the activity and the data |
| Some work, if outsourced | Reputational damage |
| Regulatory duties and fines (often uninsurable) | |
| Harm to customers |
Acceptance is a decision, not a shrug
Mixing responses
Responses can be combined. A legacy system can't support MFA, and replacing it costs 2 million and takes 18 months.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Buying cyber insurance is… | Risk transfer |
| Does insurance transfer responsibility? | No; only financial impact |
| Stopping an activity because the risk is too high | Avoidance |
| Who can accept residual risk | The business risk owner / senior management |
| Requirement for valid acceptance | Informed, documented decision at the right level |
| Response when risk is within appetite | Acceptance, with monitoring |
Key takeaways
- ✓Mitigate: reduce how likely or how bad the risk is, with controls.
- ✓Transfer: shift the financial impact to someone else, through insurance or contracts.
- ✓Avoid: stop doing the activity that creates the risk.
- ✓Accept: knowingly live with the risk, because it's within appetite or fixing it costs more than it saves.
- ✓Transferring risk moves money, not accountability; reputational and regulatory impact stay with you.
- ✓Accepting a risk is a documented decision by someone with authority, not just ignoring it.
Exam traps
- !Insurance transfers financial loss, not responsibility or reputational damage.
- !Ignoring a risk is not acceptance; acceptance is informed, documented and approved.
- !Outsourcing a process doesn't transfer accountability for it.
- !Avoidance is the only response that removes the risk completely, and you lose the activity's benefits too.
- !IT staff can't accept business risk on the business's behalf.
Risk Appetite and Residual Risk
How much risk an organisation is willing to take, how that differs from how much it could survive, and why the goal of controls is 'acceptable', not 'zero'.
How much risk is OK?
No organisation can remove all risk; doing business means taking some. The question is how much is acceptable.
Think of a family deciding how risky their investments should be. Young savers might accept big swings for bigger returns; a family about to retire wants safety. Organisations make the same kind of choice, and it's called risk appetite.
Capacity, appetite, tolerance
Inherent to residual
- 1 Inherent risk Before any controls.
- 2 Controls Reduce likelihood or impact.
- 3 Residual risk What remains.
- 4 Compare with appetite Within? Owner accepts it. Above? Treat more or escalate.
The auditor's yardstick
| Residual risk compared with appetite | What it means |
|---|---|
| Well below | May be over-controlled; could save money |
| Within | Controls are adequate; owner accepts; monitor |
| Above | Report it; more treatment or higher-level acceptance needed |
| No appetite defined | Nobody can judge if controls are enough: a finding in itself |
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who sets risk appetite | The board |
| Risk remaining after controls | Residual risk |
| Goal of controls | Reduce residual risk to an acceptable level |
| Residual risk exceeds appetite | More treatment, or acceptance at a higher level |
| Appetite vs tolerance | Appetite is overall; tolerance is variation for specific goals |
Key takeaways
- ✓Risk appetite is how much risk the organisation is willing to take to achieve its goals. The board sets it.
- ✓Risk tolerance is the acceptable variation around specific goals; risk capacity is the most risk the organisation could bear.
- ✓Inherent risk is the risk before controls; residual risk is what's left after controls.
- ✓Residual risk should be within appetite and formally accepted by the risk owner.
- ✓Residual risk is never zero; the aim is an acceptable level.
- ✓The auditor uses appetite as the yardstick when judging whether controls are adequate.
Exam traps
- !Controls aim for acceptable residual risk, not zero risk.
- !Appetite is set by the board, not by IT or the CISO.
- !If residual risk is above appetite, more treatment or higher-level acceptance is needed.
- !Tolerance is narrower and more specific than appetite.
Maturity Models (CMMI)
Rating how well-run a process is on a scale from chaotic to continuously improving, what each CMMI level means, and why the right target isn't always the top.
How grown-up is this process?
Two kitchens can both serve good food. In one, it depends on the head chef's mood that day. In the other, there are standard recipes, everyone follows them, results are measured, and the recipes keep getting better.
Maturity models put a number on that difference.
The five CMMI levels
Telling neighbouring levels apart
| Levels | What changes |
|---|---|
| 1 → 2 | Basic planning and tracking; success can be repeated |
| 2 → 3 | Standard processes across the WHOLE organisation, not just some projects |
| 3 → 4 | Processes measured and controlled with data |
| 4 → 5 | Systematic, continuous improvement |
Using a maturity assessment
- 1 Rate today Current level for each key process.
- 2 Set a target Based on business need and risk.
- 3 Find the gap Which practices are missing?
- 4 Plan Prioritise improvements; reassess later.
The right target isn't always 5
A small company doesn't need level 5 change management. A critical regulated process might need level 3 or 4. The auditor compares the current level with the target the organisation set, not with the maximum. And maturity describes discipline; it doesn't prove a particular control worked.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Level with organisation-wide standard processes | Level 3, Defined |
| Level focused on continuous improvement | Level 5, Optimising |
| Level using quantitative measurement | Level 4 |
| Main use of a maturity model | Find the gap between current and target maturity |
| The right target level | Based on business need and risk |
Key takeaways
- ✓Maturity models describe how well-defined, managed and improved processes are, on a staged scale.
- ✓CMMI levels: 1 Initial, 2 Managed, 3 Defined, 4 Quantitatively managed, 5 Optimising.
- ✓Level 2 is project-level discipline; level 3 is one standard process across the organisation; level 4 uses measurement; level 5 focuses on continuous improvement.
- ✓COBIT 2019 rates process capability 0 to 5 on a CMMI-based scale.
- ✓Organisations should set a target level based on business need; not every process needs level 5.
- ✓A maturity assessment shows the gap between current and target, which guides improvement.
Exam traps
- !The difference between levels 2 and 3 is whether processes are standardised across the whole organisation.
- !Level 4 is about measurement; level 5 is about continuous improvement.
- !Higher maturity isn't automatically the right recommendation; it depends on need and cost.
- !Maturity doesn't prove a specific control works; it describes process discipline.
KPIs and KGIs
Three kinds of indicator: did we reach the goal (KGI), is the process on track (KPI), and is risk growing (KRI). Plus what makes a metric actually useful.
Three questions, three indicators
Think about a marathon runner. Their finishing time is the result (a goal indicator). Their weekly training distance shows whether they're on track (a performance indicator). A sore knee is an early warning that something could go wrong (a risk indicator).
IT governance uses the same three kinds of measure.
KGI, KPI and KRI
What makes a metric useful
Activity vs outcome
IT reports '500 incidents closed this month' as its headline number. That's just activity: it doesn't say whether services are good.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Indicator measuring whether a goal was achieved | KGI |
| Indicator measuring process performance | KPI |
| Indicator giving early warning of rising risk | KRI |
| Best measure of awareness training | A behaviour or outcome measure, not attendance |
| What makes a metric actionable | A target or threshold, an owner, timely reporting |
Key takeaways
- ✓A key goal indicator (KGI) measures whether a goal was achieved: an outcome, measured afterwards (lagging).
- ✓A key performance indicator (KPI) measures how well a process is working, and whether the goal is likely to be met (leading).
- ✓A key risk indicator (KRI) signals that risk exposure is changing, giving early warning.
- ✓Good metrics are specific, measurable, linked to goals, timely, and owned by someone.
- ✓Metrics need targets or thresholds, and someone who acts when they're missed.
Exam traps
- !KGI = did we achieve the goal? KPI = how well is the process working towards it?
- !Counting activity (training sessions delivered) is weaker than measuring outcomes (fewer phishing clicks).
- !A metric with no target or owner rarely leads to action.
- !KRIs need thresholds that trigger escalation.
Outsourcing: Benefits and Risks
Why organisations hand IT work to outside providers, what can go wrong, the controls that keep it safe, and the one rule the exam never lets go of: accountability stays with you.
Hiring someone else to do it
Plenty of organisations hand IT work to specialists: payroll processing, data centres, the service desk, whole applications. Done well, it brings skills and savings. Done badly, it brings outages, breaches and lock-in.
And whichever way it goes, the organisation remains accountable. The exam returns to this again and again.
Benefits and risks
The outsourcing life cycle
Controls that keep it safe
Accountability in action
A bank outsources card processing. The processor is breached. Regulators fine the bank, which is still accountable for its customers' data. Whether the bank can recover any of its losses depends entirely on what the contract says about liability.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Who stays accountable for an outsourced function | The outsourcing organisation |
| Most important contract clause for the auditor | Right to audit |
| What to do before choosing a vendor | Due diligence |
| Greatest risk of outsourcing | Loss of control, with accountability still yours |
| How to get assurance over a vendor | SOC reports, certifications, or a right-to-audit review |
Key takeaways
- ✓Accountability for outsourced functions stays with the organisation; only the work moves.
- ✓Benefits: access to skills, lower or predictable costs, flexibility, and focus on the core business.
- ✓Risks: loss of control and knowledge, vendor lock-in, vendor failure, data protection, and hidden costs.
- ✓Key controls: due diligence before choosing, a strong contract with SLAs and a right to audit, ongoing monitoring, and an exit plan.
- ✓Keep enough in-house skill to manage the vendor and the contract.
- ✓Assurance over the vendor comes from audits, SOC reports, certifications and performance monitoring.
Exam traps
- !Outsourcing doesn't transfer accountability, legal responsibility or regulatory duties.
- !Cost savings aren't guaranteed; count transition, oversight and exit costs.
- !Without a right-to-audit clause, you only get whatever reports the vendor chooses to share.
- !Plan the exit at the start, not when things go wrong.
- !Due diligence happens before signing; monitoring happens throughout.
Vendor Selection, Contracts, SLAs, Right to Audit
Choosing a vendor properly, what a good IT contract contains, how service level agreements work, and why 'right to audit' and 'escrow' matter.
Choosing a vendor
Choosing an IT vendor is like hiring a builder. Get it wrong and you live with the consequences for years. So the process matters: know what you need, compare options fairly, check the vendor out, and get a solid contract.
What a good contract covers
Anatomy of an SLA
| Part | Example |
|---|---|
| Service | Hosting the CRM platform |
| Target | 99.9% availability per month, excluding agreed maintenance |
| Measurement | Vendor monitoring, checked by the customer's own tests |
| Reporting | Monthly report; review meeting |
| Consequence | Service credits; right to end the contract after repeated failures |
Software escrow
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step in choosing a vendor | Define requirements |
| Clause letting the auditor review vendor controls | Right to audit |
| Protection if a software vendor goes bust | Source code escrow |
| SLA has no measurement method | Can't be monitored or enforced |
| Who owns customer data held by a vendor | The customer; the contract should say so |
Key takeaways
- ✓Vendor selection follows a process: requirements, RFI or RFP, evaluation against weighted criteria, due diligence, and approval.
- ✓Contracts should cover scope, service levels, security and privacy duties, confidentiality, data and IP ownership, liability, right to audit, sub-contracting and termination.
- ✓An SLA sets measurable service targets, how they're measured and reported, and what happens if they're missed.
- ✓A right-to-audit clause lets the customer, its auditors and regulators check the vendor's controls.
- ✓Source code escrow protects the customer if a software vendor fails or stops support.
- ✓Legal should review contracts before signing; changing them later is harder and costlier.
Exam traps
- !The first step in choosing a vendor is defining requirements, not inviting bids.
- !An SLA with no defined way to measure it can't be enforced.
- !Escrow only helps if the deposited code is complete, current and verified.
- !Ownership of data must be stated clearly, including its return and destruction on exit.
- !Penalties don't restore service; SLAs must be actively monitored.
Cloud and Offshore Governance
Who's responsible for what in the cloud, why data location matters, how to get assurance over a cloud provider, and the extra risks of offshore outsourcing.
Renting instead of owning
Cloud computing is renting IT instead of owning it. Like renting a home, the landlord looks after some things and you look after others, and arguments start when nobody's sure who fixes what.
The three main models differ in how much the provider handles.
Who looks after what
Cloud governance worries
Offshore outsourcing
Outsourcing to another country adds its own risks.
| Risk | How to manage it |
|---|---|
| Different laws, hard to enforce contracts | Contract under home law; legal advice |
| Personal data leaving the country | Legal transfer mechanism; minimise data |
| Political or economic instability | Country risk assessment; continuity plans |
| Language, culture, time zones | Clear SLAs, regular governance meetings |
| Hard to audit on site | Independent reports; remote audits; right to audit |
Shadow IT in action
The marketing team signs up for a cloud analytics tool on a credit card and uploads customer lists. The provider stores data in another region, and nobody checked its security.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| What the customer is always responsible for | Its data and access management |
| Main concern with data stored abroad | Jurisdiction and privacy law |
| Assurance over a large cloud provider | Independent reports, checked for scope |
| Risk of departments buying cloud directly | Shadow IT bypassing governance |
| Key thing to plan before choosing a provider | Exit strategy and data portability |
Key takeaways
- ✓IaaS, PaaS and SaaS shift different amounts of work to the provider, but the customer always owns its data, its users and their access.
- ✓The shared responsibility split must be understood and written down; gaps appear where each side assumes the other is covering something.
- ✓Where data is stored decides which laws apply, affecting privacy, government access and disputes.
- ✓Assurance over large cloud providers usually comes from independent reports (SOC 2, ISO 27001, CSA STAR), not direct audits.
- ✓Offshore outsourcing adds legal, political, language, time zone and audit-access risks.
- ✓Plan exit and data portability from the start.
Exam traps
- !Moving to the cloud doesn't transfer accountability for protecting data.
- !In SaaS, the customer still manages user access and data classification.
- !A provider's certificate must cover the services and regions you actually use.
- !Data stored in another country may fall under that country's laws.
- !Shadow IT (departments buying cloud services directly) bypasses governance.
Portfolio and Resource Management
Treating IT spending like an investment portfolio: choosing the best mix of projects, stopping the ones that no longer make sense, and managing people, budgets and software licences.
IT spending as an investment portfolio
A sensible investor doesn't put all their money into whichever stock their friend recommends most loudly. They choose a balanced mix, review it regularly, and sell what's no longer working.
IT portfolio management does the same with IT projects and services.
Portfolio, program, project
What portfolio management does
- 1 Evaluate Score business cases: value, fit, risk, cost.
- 2 Select Fund the best mix within budget and capacity.
- 3 Balance Keep the lights on, grow, transform.
- 4 Monitor Track benefits, cost and risk.
- 5 Adjust or stop Kill what no longer makes sense.
Managing IT resources
| Resource | Key controls |
|---|---|
| People | Skills planning; avoid relying on one key person |
| Budget | Linked to strategy; variances explained; costs allocated fairly |
| Infrastructure | Capacity planning; asset management |
| Software licences | Inventory; compare licences owned with installs; restrict installation |
Licences in practice
A licence check finds 1,200 copies of a design tool installed, but only 800 licences. Users have admin rights on their laptops and install it themselves.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Main purpose of IT portfolio management | Get the most value from IT investment, aligned with strategy |
| Basis for prioritising projects | Business cases: value, alignment, risk, resources |
| Project no longer viable but much spent | Stop or redirect it |
| Best control over licence compliance | Inventory and reconciliation; restrict installation rights |
| Program vs project | A program groups related projects for one outcome |
Key takeaways
- ✓Portfolio management treats IT investments as a portfolio, selected and balanced to deliver the most value for strategy and risk.
- ✓Projects are prioritised using business cases, strategic fit, risk and available resources.
- ✓The portfolio is reviewed regularly; failing investments are changed or stopped.
- ✓IT budgets should follow the strategy; chargeback or showback makes IT costs visible to the business.
- ✓Resource management covers people, infrastructure, applications and information, including software licence compliance.
- ✓Portfolio = all investments; program = related projects with a shared outcome; project = one time-bound piece of work.
Exam traps
- !Approving projects one at a time, with no portfolio view, leads to duplicated and misaligned spending.
- !Continuing a failing project because of money already spent (sunk cost) is a governance failure.
- !Unlicensed software is a legal and financial risk.
- !Chargeback can encourage efficient use, but must be fair and transparent.
HR: Hiring, Training, Termination
The people controls that matter for IT and security: screening new staff, training, job rotation and mandatory leave, and removing access when people move or leave.
People are part of security
Many IT controls quietly depend on HR. You can't remove a leaver's access if nobody tells IT they've left. You can't trust someone with payroll data if nobody checked their background.
The exam follows the employee from hiring to leaving.
While they work
Leaving done right
When leaver controls fail
The auditor matches HR's leaver list to VPN accounts and finds 14 people who left over a month ago still active, including a dismissed systems administrator. IT finds out about leavers by email, which is often missed.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Most important control when someone leaves | Prompt removal of all access |
| Timing for a dismissal | Remove access when the person is told |
| Control that detects fraud needing constant hiding | Mandatory leave or job rotation |
| Best test of leaver controls | Match HR leavers to active accounts |
| Risk when staff change roles | Access creep; remove old access |
Key takeaways
- ✓Hiring controls: background checks suited to the role, references, and signed confidentiality and acceptable use agreements.
- ✓Staff get security awareness training when they join and regularly after.
- ✓Job rotation and mandatory leave help uncover fraud and reduce reliance on one person.
- ✓When people leave, all access must be removed promptly; for dismissals, at the moment they're told.
- ✓Leaving also means collecting laptops, badges and tokens, and removing physical and remote access.
- ✓When people change roles, old access must be removed so it doesn't pile up.
Exam traps
- !For an involuntary termination, access is removed when the person is told, not at the end of their notice.
- !HR telling IT is the trigger. Without a reliable HR-to-IT process, leavers stay active.
- !Contractors and temps need the same leaver process.
- !Access creep happens when people move roles, not just when they leave.
- !Mandatory leave is a detective control, not a perk.
Legal and Regulatory Compliance
How an organisation keeps track of the laws, regulations and contracts that affect its IT, and how an auditor checks it's on top of them.
Rules from every direction
Organisations face rules from many sources: privacy laws, financial regulations, industry rules, contracts with customers and suppliers. Breaking them can mean fines, lawsuits or losing the right to operate.
Keeping track of them all needs a process, not good intentions.
Typical IT-related obligations
The auditor's approach
- 1 Identify Which requirements apply here?
- 2 Review the process How does management track and meet them?
- 3 Test controls The key ones for each requirement.
- 4 Ask the lawyers Legal counsel for interpretation.
- 5 Report Non-compliance to the right level.
A missed obligation
A new HR system stores employees' health information, which privacy law treats as especially sensitive. No privacy impact assessment was done, and the compliance team didn't even know the system existed.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| First step in a compliance audit | Identify the laws and regulations that apply |
| Who is responsible for compliance | Management |
| Auditor unsure how a law applies | Consult legal counsel |
| Keeping policies in line with new rules | A process for tracking regulatory change |
| Is PCI DSS a law? | No; a contractual obligation treated as a compliance requirement |
Key takeaways
- ✓Management is responsible for knowing which laws and regulations apply and for complying with them.
- ✓A compliance process needs a list of requirements, owners, controls mapped to each requirement, monitoring and reporting.
- ✓IT-related obligations include privacy, financial reporting (such as SOX), sector rules, card data (PCI DSS), licensing and record retention.
- ✓The auditor's first step is identifying which requirements apply, then checking the organisation has a process to meet them.
- ✓The auditor isn't a lawyer; legal questions go to legal counsel.
- ✓Regulatory changes must be tracked so policies and controls stay current.
Exam traps
- !The auditor's first step is understanding which requirements apply, not testing controls.
- !Compliance is management's responsibility, not internal audit's.
- !On suspecting an illegal act, the auditor reports it internally; they don't decide the legal outcome.
- !Contractual obligations, like PCI DSS through card agreements, count as compliance requirements even though they aren't laws.
Quality Management
Making sure IT delivers consistently good results: quality management systems, ISO 9001, and the difference between quality assurance and quality control.
Consistently good, not occasionally good
Quality management is about getting good results every time, not by luck. A quality management system (QMS) sets out the policies, processes and checks that make that happen, and keeps improving them.
ISO 9001 is the certifiable standard for a QMS.
QA vs QC
Parts of a QMS
QA in name only
Developers mark their own changes as 'QA passed' in the ticket system. On paper there's a QA step, but it's done by the people who wrote the code.
How the exam asks about it
| If the question asks… | Answer |
|---|---|
| Difference between QA and QC | QA: process, preventive. QC: product, detective |
| Certifiable QMS standard | ISO 9001 |
| Testing completed software is… | Quality control |
| Concern when QA reports to development | Lack of independence |
Key takeaways
- ✓A quality management system (QMS) defines how an organisation makes sure its products and services meet requirements.
- ✓ISO 9001 sets out requirements for a QMS and can be certified.
- ✓Quality assurance (QA) is about the process and prevents defects.
- ✓Quality control (QC) is about the product and detects defects.
- ✓Software quality standards such as ISO/IEC 25010 define qualities like reliability, security and maintainability.
- ✓QA must be independent of the teams whose work it reviews.
Exam traps
- !QA = process, preventive. QC = product, detective.
- !Testing a finished system is QC; setting standards and checking they're followed is QA.
- !ISO 9001 certification shows a QMS meets the standard, not that every product is perfect.
- !QA reporting to the development manager isn't independent.