CISA Enterprise Risk Management, Privacy and Data Governance

An IS auditor evaluates an enterprise risk management (ERM) program by checking that the board has set the amount of risk the enterprise will take, that every significant risk, IT risk included, is identified and rated on common terms, and that each risk decision is made against that board-approved limit by someone with the authority to make it. ERM is the enterprise-wide process for identifying, assessing, responding to and monitoring risk to the organization's objectives. Common frameworks are COSO Enterprise Risk Management – Integrating with Strategy and Performance and ISO 31000; for IT risk, ISACA's COBIT 2019 and its risk guidance apply the same ideas.

Risk appetite comes first

Risk appetite is the amount and type of risk the enterprise is willing to pursue or retain in pursuit of its objectives. It is set and approved by the board (or a board risk committee), usually on a proposal from the chief risk officer (CRO) and executive management. Risk tolerance is the acceptable variation around that appetite for a particular objective or risk, often expressed as thresholds that trigger escalation. Without an approved appetite there is no reference point: nobody can say whether a residual risk is acceptable, whether an acceptance was made at the right level, or whether the register's priorities are right. That is why a missing or unapproved appetite statement is a foundational ERM weakness: flaws in method or process can be corrected inside the program, but without an appetite there is nothing to measure any risk decision against.

IT risk must be part of enterprise risk

IT risk is business risk: it matters because of what an IT failure does to revenue, customers, compliance and operations. An IT risk register kept apart from the enterprise register, rated on a technical scale that cannot be converted to the enterprise's impact terms, cannot be compared with credit, market or operational risks when the enterprise sets priorities and allocates money. The auditor looks for common criteria (the same likelihood and impact definitions, expressed in business terms) and a link that lets IT risks roll up into the enterprise view. However the registers are organized, the test is comparability: can every risk be ranked against every other on the same terms?

What the auditor examines

• A board-approved risk appetite and tolerances, and reporting of risk against them to the board.
• A documented methodology: risk categories, rating scales, assessment frequency and change triggers.
• Defined ownership: a named risk owner for every risk and a control owner for every key control.
• Delegated authority for accepting risk, and evidence that acceptances respected it.
• A current register, with treatment plans for risks outside appetite and tracking to completion.

The auditor evaluates and reports; management owns the program. The auditor does not set the appetite, rate the risks or accept them. Ownership of IT policies and standards, the third part of the ownership task, is covered in the previous lesson on IT governance.

A risk owner is the accountable business manager whose objectives the risk affects; a control owner is the person responsible for operating a control that reduces it. These are different roles, and confusing them is a common audit finding.

When IT is named as the owner of every risk, including risks to business processes, nobody with authority over those processes is accountable for the decision to treat or accept them. IT runs systems and controls; it cannot decide how much risk the sales or finance function should carry. The fix is to assign each risk to the business manager accountable for the affected process; the risk function facilitates and reports, and control owners operate the responses the risk owner chooses.

Acceptance authority and escalation

Accepting a risk is a decision to live with the residual risk, so it must be made by someone with authority for that level of exposure. Organizations delegate acceptance limits: a manager can accept risks within appetite up to a set rating, while risk above appetite must be escalated to, and accepted by, the level the organization's delegation scheme reserves for it (typically senior management, the board or its risk committee). An acceptance made below that level is not valid, whatever form it takes. The auditor's role is to report the missing approval and the exposure it leaves to management at the appropriate level; choosing the treatment remains management's decision, not the auditor's.

Aggregation

Several teams may each accept a slice of the same risk, such as a vulnerability in an open-source component that all of their products embed, each within its own limit. Separately they look acceptable; together the exposure may exceed the enterprise appetite. A sound ERM program aggregates related risks with a common cause before comparing them with appetite, and that aggregation is one of the risk function's core jobs.

A risk assessment identifies the information assets and their value first, then the threats and vulnerabilities that could harm them, then the likelihood and impact of each risk, and finally the controls that reduce it. The order matters: until you know what you are protecting and what it is worth to the business, you cannot judge which threats matter or how much protection is proportionate.

1. Identify assets and their value — information, systems, processes and people, valued by their importance to business objectives (often drawn from the data inventory and business impact analysis).
2. Identify threats and vulnerabilities — what could cause harm (attackers, failures, errors, disasters) and the weaknesses that could be exploited.
3. Assess likelihood and impact — qualitatively (high/medium/low scales with defined meanings) or quantitatively (monetary estimates).
4. Evaluate existing controls — and determine the residual risk with those controls in place.
5. Compare with appetite and choose a response — then record the result in the risk register.

Qualitative analysis is quick and works where data is scarce, but ratings are subjective and hard to add together. Quantitative analysis supports cost–benefit decisions but depends on the quality of the estimates. Many organizations combine them: qualitative screening, quantitative analysis for the largest risks. Either is acceptable to an auditor if the scales are defined, applied consistently and comparable across the enterprise.

Inherent, residual and target risk

Inherent risk is the risk before controls are considered, residual risk is the risk that remains with the controls currently operating, and target risk is the level management plans to reach once planned controls are in place. Risk appetite is compared with residual risk, because that is the exposure the enterprise actually carries today.

A residual rating is only as good as the assumption that the controls it relies on actually work. Suppose management rated a data-loss risk low because nightly backups can be restored, and the auditor finds the restore tests have failed for months: the control is not reducing the risk as assumed, so the residual rating is understated and the risk may be outside appetite. Only controls that operate as designed count towards residual risk; a control that is merely planned contributes to the target position, not the current one.

Quantitative risk analysis expresses risk as an expected annual loss, the annualized loss expectancy (ALE), so that it can be compared directly with what a control costs each year. Three figures build it:

Worked example (illustrative figures): an application worth $600,000 would lose 30% of its value in an outage expected once every five years. SLE = $600,000 × 0.30 = $180,000. ARO = 1 ÷ 5 = 0.2. ALE = $180,000 × 0.2 = $36,000 a year.

The decision rule: a control is cost-justified when the reduction in ALE it achieves is greater than its annual cost (purchase spread over its life plus running costs). A control that removes the whole risk above can therefore cost at most $36,000 a year. Two errors are common: comparing the control's annual cost with a single loss (SLE), which ignores how rarely the event happens, and comparing it with the asset value, which ignores both frequency and the exposure factor. A control that only partly reduces the risk is justified by the ALE it removes (ALE before minus ALE after), not the full ALE.

Quantitative results still need judgement: some impacts, such as loss of life, legal sanctions or reputation, are hard to price, and an auditor may recommend a control on those grounds even where the ALE arithmetic is marginal.

There are four ways to respond to a risk: accept it, mitigate (reduce) it with controls, transfer (share) part of it to another party, or avoid it by stopping the activity that causes it. The right choice depends on the residual risk against appetite, the cost of each option and whether the activity is worth keeping.

Insurance is the classic misunderstanding. A cyber policy can pay for recovery costs and some losses, but it does not prevent the outage, restore customer trust or remove the organization's legal and regulatory accountability. Recording a risk as "closed" because insurance was bought overstates the treatment; the risk remains, partly transferred, and the non-financial impact still needs a response. Insurance is transfer, not avoidance, and buying it does not change the appetite.

Avoidance is often overlooked because it is not a control. When an activity delivers less value than the cost of making it safe, and the business can do without it, stopping it removes the risk entirely, often more cheaply than any control. For example, a retailer that stores card numbers only to speed up repeat orders can stop storing them, removing that exposure rather than securing it.

A risk register stays reliable only if management reassesses risks at defined intervals and whenever a significant change occurs, such as a migration to the cloud, an acquisition, a new regulation, a major incident or a new product. Periodic review alone misses the risks a change introduces between cycles; event-driven review alone lets slowly drifting risks go stale.

Consider an organization that acquired a competitor and absorbed its systems and customer base, but whose register still lists only its original risks. It no longer describes the real exposure: inherited systems, integration links and new data sets are missing, and existing ratings may rest on controls the change has altered. The auditor recommends a reassessment process with both triggers, scheduled and event-driven, and looks for evidence that it runs. The register is management's tool; auditors give assurance over it rather than maintaining it, and the frequency of review should be proportionate to the risk.

A current register also records, for each risk: the owner, inherent and residual ratings, the chosen response and its rationale, treatment actions with owners and due dates, and the date of the last review. Key risk indicators (KRIs) that warn of rising exposure are monitored by management; how KPIs and KRIs are designed and reported is covered in the IT management lesson.

A privacy program is the set of governance, policies, processes and controls that ensures an organization collects, uses, shares, retains and disposes of personal data as the law and its own commitments to individuals require. Privacy is about the proper use of personal data; security is about protecting it. Encryption, breach notification and access rights are parts of a program, but none is its objective.

The core principles

The EU GDPR Article 5 principles and similar laws, along with frameworks such as the OECD Privacy Guidelines, ISO/IEC 29100 and the privacy criteria in the AICPA Trust Services Criteria, share the same core principles (the OECD Guidelines cover storage limitation only implicitly, through purpose specification and use limitation):

Exam scenarios usually describe one of these clearly: extra collection is a minimization problem, a new use is a purpose-limitation problem, endless keeping is a storage-limitation problem. Identify what the data was collected for, then compare what is being done with it.

Evidence that the program works

Documentation shows that a program is designed and communicated; it does not show that personal data is actually processed as promised. The strongest evidence comes from testing actual processing against the documented purposes, lawful bases and consents: for example, sampling personal data shared with third parties and tracing each disclosure to a recorded purpose and basis. This follows the general audit rule that evidence the auditor obtains by re-performing or tracing outcomes is more reliable than statements, configurations or descriptions of intended practice.

A privacy impact assessment (PIA), called a data protection impact assessment (DPIA) under the GDPR, is a structured analysis of how a proposed processing activity affects individuals' privacy, done before the processing starts so that the risks can be designed out. It is the practical tool of privacy by design and by default.

When a PIA is needed and when it must be revisited

• Before building high-risk processing: profiling or prediction from combined data, large-scale sensitive data (health, biometrics, location), systematic monitoring, new technologies. Security reviews ask whether data is protected; a PIA asks whether the processing itself is necessary, proportionate and lawful, so one cannot stand in for the other.
• Again when the processing changes significantly (GDPR Article 35(11)), for example when a customer app assessed for account data later adds continuous location tracking. The update belongs before the change goes live, while the risks can still be designed out; the timing rule is the same as for the original assessment.

Cross-border transfers: lawful before secure

Many privacy laws restrict transfers of personal data to other countries. The GDPR, for example, allows them only on a recognized basis such as an adequacy decision, standard contractual clauses or binding corporate rules, and other jurisdictions have their own conditions or data-localization rules. When an organization plans to outsource processing abroad, the first question is whether the law permits the transfer and whether its conditions are met; assessing the provider's security and assurance is the second question, not the first.

An outsourcing agreement that lets a payroll processor engage sub-processors in any country without notice makes lawful transfer impossible to demonstrate, because the organization cannot say where its data goes. The control is contractual: specify the countries or regions where data may be stored and processed, and require notice and approval before sub-processors or locations change. Location is a legal question, so it needs a legal control.

Data governance is the framework of roles, policies and processes that makes the business accountable for its data: who owns it, how it is classified, who may use it and how its quality, retention and disposal are managed. An IS auditor evaluates whether those roles are defined and exercised, and whether classification drives the controls actually applied.

The owner's approval must come before access is granted. When a service desk grants access to the general ledger whenever a project lead asks in chat, the custodian is effectively deciding access to data it does not own. Reviews after the fact are detective: they find inappropriate access once it exists. The preventive control is the owner's approval of each request before it is fulfilled.

What classification is for

Classification sorts information into levels (for example public, internal, confidential, restricted) so that protection is proportionate to its value and sensitivity: strong controls where they matter, lower cost where they do not. Each level carries handling rules for labelling, access, storage, transmission, retention and disposal.

• Inventory and ownership first. After a scheme is approved, the next step is an inventory of information assets with a named owner for each, because only owners can classify. Every enforcement control depends on knowing what the data is and how it is classified.
• Aggregation. Combined data can be more sensitive than its parts: a dataset linking staff names with badge-swipe times and building locations can reveal daily movements and warrant a higher level than each field alone. The whole dataset is assessed, not just its fields, and the classification is decided by the owner, not by the platform or the analyst who built it.

Alignment with the privacy program and external requirements

Classification must align with the data governance program, the privacy program and the external requirements that apply, such as PCI DSS for payment card data, health-data laws for health records and national rules for identity numbers. Different regimes can share one level only if that level's handling rules meet the strictest requirement of each; otherwise the data needs its own level or additional rules. No standard prescribes a number of levels (ISO/IEC 27001 Annex A includes a classification control, 5.12 in the 2022 edition, but leaves the scheme and the number of levels to the organization). When an organization enters a new jurisdiction, the first step is to map that jurisdiction's legal requirements onto the classification and handling rules; the controls follow from that mapping.

Every category of data needs a retention period grounded in its legal, regulatory and business requirements, followed by secure disposal or anonymization when the period ends. A retention schedule that covers some categories but leaves others, such as supplier and contractor files, to be kept indefinitely breaks the storage-limitation principle and increases breach impact and discovery costs.

• Periods are set per category from what the law requires (tax, employment, sector rules) and what the business genuinely needs; the data owner proposes them and legal/compliance confirms them, so each period can be justified for its own category.
• Disposal must be verifiable and cover copies and backups according to the schedule.

Erasure requests versus legal obligations

A right to erasure is not absolute. Under the GDPR (Article 17(3)), for example, data needed to comply with a legal obligation may be kept. When a former employee asks for erasure but employment law requires payroll records to be kept for a set period, the balanced response is to keep only the data the law requires, restrict its use to that purpose, and erase everything else now; the retained records are erased when their period ends. Each obligation is met in full for the data it actually covers.