Cyber Risk, Controls and Third-Party Compliance

Introduction and Context

Cybersecurity is not only a technical function. It is also a legal, ethical and governance responsibility. An organisation may use firewalls, encryption and security software, yet still fail to comply with law if it ignores privacy duties, contracts, breach notification requirements, records management or the conduct of suppliers. Cyber risk management provides a structured way to identify what may go wrong, estimate its significance, select proportionate controls and monitor whether those controls remain effective.

Cyber risk is the possibility that a cyber event will adversely affect the confidentiality, integrity or availability of information or systems, or cause legal, financial, operational, safety or reputational harm. Compliance adds a further dimension: an organisation must be able to demonstrate that it has met applicable legal, regulatory, contractual and internal obligations.

This chapter introduces practical risk assessment, control selection and third-party due diligence. It relates these activities to ISO/IEC 27001, the NIST Cybersecurity Framework (CSF), and sector requirements. The emphasis is on foundational professional practice suitable for a compliance officer, junior risk analyst, procurement officer, system administrator or information-security coordinator.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain cyber risk, assets, threats, vulnerabilities, impacts and controls.
2. Conduct a basic likelihood-impact risk assessment.
3. Select preventive, detective, corrective and compensating controls.
4. Distinguish between legal, regulatory, contractual and voluntary standards-based obligations.
5. Compare the practical roles of ISO/IEC 27001 and the NIST CSF.
6. Perform basic vendor due diligence and identify third-party compliance risks.
7. Recommend proportionate treatment, monitoring and escalation actions.

1. Foundations of Cyber Risk

1.1 Assets, threats and vulnerabilities

An asset is something that has value to an organisation or its stakeholders. Assets include personal data, payment information, source code, medical records, devices, cloud services, business processes, facilities, intellectual property and organisational trust.

A threat is a potential cause of harm. Threat sources may be external criminals, insiders, competitors, hostile states, hacktivists, natural events or suppliers. A threat becomes relevant when it has both an opportunity and a plausible path to an asset.

A vulnerability is a weakness that can be exploited or triggered. Examples include unpatched software, excessive privileges, weak passwords, insecure application programming interfaces, poor physical security and inadequate supplier oversight. A vulnerability does not automatically produce loss; it contributes to risk when combined with a threat and an exposed asset.

A cyber event is an observable occurrence, such as repeated failed logins or malware detection. A cyber incident is an event that actually or potentially compromises confidentiality, integrity or availability, or violates security policy. A data breach is a particular type of incident involving unauthorised access to, disclosure of, alteration of or loss of protected information, subject to the applicable legal definition.

1.2 The CIA triad and wider consequences

The traditional CIA triad consists of:

• Confidentiality: information is accessible only to authorised persons.
• Integrity: information and systems remain accurate, complete and trustworthy.
• Availability: authorised users can access systems and information when needed.

Cyber incidents may also affect authenticity, accountability, privacy, safety and resilience. For example, alteration of an industrial-control instruction may create a physical safety risk, while a ransomware attack may make records unavailable even though they have not been disclosed.

Impacts may include direct financial loss, interruption of essential services, regulatory penalties, litigation, contractual claims, notification costs, loss of intellectual property, discrimination or harm to individuals. A sound assessment considers affected stakeholders, not merely the organisation's immediate costs.

1.3 Inherent and residual risk

Inherent risk is the level of risk before considering controls. Residual risk is the risk remaining after controls are implemented. Controls generally reduce likelihood, impact, or both, but rarely eliminate risk completely. A risk owner must decide whether the residual risk is acceptable, requires further treatment or must be escalated.

Risk acceptance should be explicit. It should identify the decision-maker, rationale, duration, assumptions and review date. A junior employee should not accept a risk that organisational policy reserves for the board or senior management.

2. A Basic Risk-Assessment Method

Risk assessment is a reasoned process rather than a claim of mathematical certainty. A small organisation may use a five-point qualitative scale; a larger organisation may supplement it with financial modelling or scenario analysis.

2.1 Scoping and asset identification

Begin by defining the assessment boundary. State the business unit, system, process, geographical area, suppliers and information types included. Identify asset owners and classify information according to organisational policy, such as public, internal, confidential or highly restricted.

A useful asset register records the asset, owner, location, purpose, dependencies, data type, recovery requirement and applicable obligations. Asset identification should include services operated by cloud providers and vendors, not only equipment physically owned by the organisation.

2.2 Scenario-based identification

Rather than asking only “What vulnerabilities exist?”, construct realistic scenarios:

A compromised supplier account is used to access a cloud-hosted customer database, allowing personal data to be copied and later used for fraud.

The scenario identifies the threat source, attack path, affected asset, security properties at risk and possible consequences. Workshops, incident records, vulnerability reports, penetration tests, threat intelligence, audits and interviews can provide evidence. However, automated vulnerability scans do not by themselves establish business impact or legal significance.

2.3 Likelihood and impact scales

A simple five-point scale can be defined as follows:

The organisation must define the assessment period and document why a score was assigned. “Impact” should be evaluated across relevant dimensions, including confidentiality, integrity, availability, privacy, safety, finance and reputation. The highest credible dimension may be used where policy requires a conservative result.

A common screening method is:

Here, R is the risk score, L is the likelihood score and I is the impact score. Both scores are normally integers from 1 to 5, so R ranges from 1 to 25. This is an ordinal prioritisation tool, not a probability of loss and not a monetary valuation. It assumes that the organisation has deliberately chosen compatible scales and a multiplication rule. A score of 12 does not necessarily represent twice the real-world loss of a score of 6.

For example, if a phishing scenario is rated likelihood 4 and impact 3:

The organisation might classify 10–14 as “high,” but thresholds are policy choices and must be stated. A high score should trigger treatment or management review; it does not automatically dictate one particular control.

2.4 Risk treatment

Common treatment options are:

• Avoid: stop the activity or redesign it so the risk no longer arises.
• Reduce/mitigate: implement controls that lower likelihood or impact.
• Transfer/share: use insurance or contractual allocation, while recognising that legal and ethical responsibility may remain.
• Accept: consciously retain the risk within approved tolerance.

Risk transfer is not a substitute for due care. A contract may allocate costs between parties, but it may not remove statutory duties owed to individuals or regulators.

3. Controls and Control Selection

A control is a measure that modifies risk. Controls may be administrative, technical, physical or a combination. They should be selected according to the risk scenario, legal duties, business need, feasibility and cost—not because a particular technology is fashionable.

3.1 Control purposes

Controls may be manual, automated or hybrid. They may also be general IT controls, such as access management and change control, or application controls, such as validation of payment fields.

3.2 Control design and operation

A control is effective only if it is properly designed and operates consistently. A quarterly access review may be well designed but ineffective if reviewers approve every account without evidence. Control testing should examine:

1. The control objective: what risk is it intended to address?
2. The responsible owner and frequency.
3. The population or systems covered.
4. Evidence that the control operated.
5. Exceptions, remediation and follow-up.

Controls should follow least privilege, defence in depth, secure-by-design and privacy-by-design principles. High-impact systems may require stronger authentication, network segmentation, tested backups and independent monitoring. Controls should also be accessible and usable; an excessively burdensome process can encourage unsafe workarounds.

3.3 Mapping controls to duties and frameworks

Legal requirements typically state outcomes or duties, such as protecting personal information, maintaining records, reporting certain incidents or safeguarding payment data. They may not prescribe one exact technology. Frameworks help translate these duties into governance and operational practices.

ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS). It uses a risk-based management system and requires consideration of interested parties, information-security objectives, leadership, planning, operation, performance evaluation and improvement. Its Annex A provides a reference set of controls; organisations select controls according to their risk treatment and document applicability. Certification, where obtained, concerns the defined ISMS scope and does not mean that every possible risk has been eliminated.

The NIST CSF 2.0 organises cybersecurity outcomes into six Functions: Govern, Identify, Protect, Detect, Respond and Recover. It is a flexible framework for communicating current and target cybersecurity outcomes. It is not itself a statute and does not automatically prove legal compliance. NIST publications such as incident-response and supply-chain guidance can support more detailed implementation.

The frameworks can be used together. ISO/IEC 27001 supplies a formal management-system and assurance structure; the NIST CSF offers accessible outcome-oriented language for organising cybersecurity activities. Neither replaces legal analysis, sector rules or contractual review.

4. Legal, Ethical and Sector Compliance

Compliance begins with an obligation register. It should identify the jurisdiction, business activity, information type, responsible owner, duty, evidence required, reporting deadline and review date. Relevant sources may include data-protection and privacy law, cybercrime law, electronic-transactions law, intellectual-property law, employment law, consumer-protection law, records legislation, financial-sector rules, health-sector rules and contractual commitments.

Legal obligations vary considerably. Some privacy laws require security safeguards, processor oversight, breach notification and data-subject rights. Financial institutions may face resilience, outsourcing, audit and incident-reporting requirements. Healthcare organisations may have heightened confidentiality and clinical-availability duties. Payment environments may be subject to the Payment Card Industry Data Security Standard (PCI DSS), a contractual and industry compliance standard rather than a universal statute. Critical-infrastructure rules may impose resilience, registration or incident-reporting duties.

A framework mapping should avoid claiming that a control “equals compliance.” Instead, it should show how a control supports a legal or regulatory requirement, identify gaps and record evidence. Legal counsel or the relevant regulator should resolve questions of interpretation, territorial scope, privilege and reporting deadlines.

Ethics extends beyond minimum legality. An organisation should consider fairness, proportionality, transparency, human dignity and foreseeable harm. For example, excessive employee surveillance may be technically lawful in one setting yet ethically unjustified. Collecting more personal data than necessary increases both privacy risk and the consequences of a breach.

5. Third-Party and Supply-Chain Compliance

Organisations depend on cloud hosts, software vendors, payment processors, managed-service providers, consultants, logistics providers and outsourced support. A supplier may have privileged access, hold regulated data or create a single point of operational failure. Third-party risk is therefore a component of enterprise risk, not merely a procurement issue.

5.1 Due-diligence lifecycle

A practical lifecycle contains the following stages:

1. Inherent-risk classification: assess data sensitivity, access, criticality, geography, concentration and substitutability before relying on the supplier's controls.
2. Pre-contract due diligence: examine ownership, financial stability, relevant experience, policies, certifications, independent assurance reports, security testing, incident history, privacy practices and subcontractors.
3. Contracting: specify security requirements, confidentiality, lawful processing, access control, encryption where appropriate, incident notification, cooperation, audit or assurance rights, business continuity, data location, retention, deletion and exit assistance.
4. Onboarding: approve accounts, minimise access, document data flows, configure integration securely and verify contact points.
5. Ongoing monitoring: review service reports, incidents, vulnerabilities, assurance evidence, performance indicators, material changes and renewal conditions.
6. Termination and exit: revoke access, retrieve or securely delete data, obtain evidence of deletion, transfer services safely and preserve required records.

A supplier questionnaire is useful but insufficient. Responses should be risk-based and corroborated. Evidence may include an ISO/IEC 27001 certificate with scope and expiry, a current independent controls report, penetration-test summary, vulnerability-management metrics, recovery-test results and documented privacy roles. A certificate covering a parent company or a different service may provide little assurance about the actual service being purchased.

5.2 Contractual safeguards

Contracts should distinguish the organisation's role from the supplier's role. Where personal data is processed, the agreement should identify instructions, permitted purposes, confidentiality, security measures, subprocessors, assistance with rights requests and incidents, deletion or return, and audit or inspection arrangements as required by applicable law.

Incident clauses should avoid vague language such as “promptly” where a definite period can be agreed. They should state the reporting channel, minimum information, update obligations, evidence preservation and responsibility for communications. The agreement must not require a supplier to delay legally mandated notification.

A service-level agreement should address security-related service commitments, such as availability targets, recovery objectives, support response, maintenance notices and credits or remedies. Availability targets do not replace recovery planning. A supplier that promises 99.9% availability may still fail during a major incident unless dependencies and recovery assumptions are tested.

5.3 Fourth-party risk

A supplier may outsource processing to another provider. This creates fourth-party risk and can obscure data location, access and accountability. The primary supplier should disclose material subcontractors, obtain required approval, flow down equivalent obligations and remain accountable for contracted performance, subject to applicable law.

6. Applied Case: A Cloud Payroll Supplier

The following is an illustrative case, not a report of a real organisation.

Background

Northbridge College, a medium-sized educational institution, plans to move payroll to a cloud service. The service will process employee names, bank details, tax identifiers, salary information and absence records. The supplier will receive administrator access for support and intends to use a subcontracted hosting provider.

Problem

Procurement initially recommends selecting the lowest-priced supplier because the supplier states that it is “fully compliant” and has an ISO certificate. The security officer identifies several unanswered questions: the certificate scope is unclear, the supplier has not stated its incident-notification period, administrator access is not protected by multi-factor authentication, and no tested exit plan exists.

Analysis

The inherent risk is high because the data is sensitive, compromise could cause financial fraud and privacy harm, payroll availability is time-critical, and the service has privileged access. A workshop rates the likelihood of a serious compromise as 3 and the impact as 5, producing a screening score of:

The score does not prove the precise probability of harm; it prioritises treatment. The assessment also identifies legal and contractual duties concerning employee privacy, retention, access, breach response and continuity of payroll.

Approach and solution

Northbridge requires the supplier to provide the certificate scope, independent assurance evidence and a current penetration-test summary. The contract requires multi-factor authentication for privileged access, unique accounts, logging, timely vulnerability remediation, confidentiality, approved subprocessors, incident notification within an agreed period, cooperation with investigations, secure deletion and tested data return. Northbridge also requires annual review and evidence of recovery testing.

A compensating control is introduced during transition: payroll exports are encrypted, access is restricted to two authorised officers, and a manual payment-continuity procedure is tested. The college records the supplier as a critical third party, assigns a risk owner and maps relevant controls to its ISMS and NIST CSF outcomes.

Outcome

The supplier passes only after narrowing administrator privileges, enabling multi-factor authentication and providing evidence that the certificate covers the payroll service. Northbridge accepts a limited residual risk relating to dependence on the hosting provider, subject to quarterly monitoring and an annual exit test.

Learning points

The case demonstrates that a supplier's marketing statement is not assurance; certification must be examined for scope and currency; risk assessment must include availability and legal consequences; contracts must be operationally specific; and third-party risk continues throughout the relationship.

7. Monitoring, Evidence and Continuous Improvement

Risk management is cyclical. New vulnerabilities, business changes, acquisitions, regulatory developments and supplier incidents can alter risk. Useful indicators include overdue critical patches, privileged accounts without multi-factor authentication, backup restoration success, unresolved high-risk findings, incident-response exercise results, supplier-review completion and time taken to revoke leavers' access.

Metrics should be interpreted carefully. A low number of reported incidents may indicate strong security—or poor detection and reporting. Measures should have defined scope, frequency, owner, data source and threshold. Audit evidence should be sufficient, reliable and traceable: approved policies, risk registers, access reviews, tickets, logs, training records, test results, meeting decisions and remediation records.

When an incident occurs, preserve evidence, activate the response plan, involve legal and privacy specialists where appropriate, assess notification duties, communicate accurately and document decisions. Do not allow a desire to protect reputation to override lawful notification or the rights of affected people.

8. Challenges and Limitations

Basic risk scoring can create false precision, especially when people assign numbers without evidence. Threats change faster than annual assessments, and interdependencies can cause correlated failures that a simple risk register misses. Frameworks can become compliance checklists rather than tools for reducing harm. Vendor questionnaires may encourage standardised answers that conceal service-specific weaknesses. Certification may provide useful assurance but has boundaries of scope, time and sampling.

Other limitations include incomplete asset inventories, uncertain threat intelligence, conflicting legal regimes, cloud concentration, shortage of skilled staff and difficulty assigning monetary value to privacy or reputational harm. These limitations should be recorded rather than hidden. Scenario analysis, independent review, testing and management judgement remain necessary.

9. Practical Best Practices

• Maintain an accurate asset, data-flow, obligation and supplier inventory.
• Assign a named owner to every material risk and control.
• Use a documented likelihood-impact method, with defined scales and review dates.
• Treat privacy, safety, integrity and availability as well as confidentiality.
• Select layered controls that are proportionate and usable.
• Map controls to legal duties without claiming that a framework replaces law.
• Verify certification scope, assurance period, exceptions and subcontractors.
• Put security, incident response, audit, deletion and exit requirements in contracts.
• Test backups, recovery, access revocation and incident communications.
• Monitor suppliers throughout the relationship and escalate material changes.
• Obtain specialist legal advice when jurisdiction, notification or regulatory interpretation is uncertain.

Chapter Summary

Cyber risk is the possibility of harm arising from threats exploiting weaknesses in valuable assets. A practical assessment defines scope, identifies assets and scenarios, evaluates likelihood and impact, selects treatment and records residual risk. The formula R = L × I can prioritise risks when compatible ordinal scales are used, but it is not a probability or monetary forecast.

Controls may prevent, detect, correct, recover, deter or compensate for unwanted events. Their effectiveness depends on design, operation, evidence and continual improvement. ISO/IEC 27001 provides a risk-based ISMS and assurance structure, while the NIST CSF organises cybersecurity outcomes through Govern, Identify, Protect, Detect, Respond and Recover. Neither framework replaces law, regulation, contracts or ethical judgement.

Third-party compliance requires risk classification, proportionate due diligence, precise contractual safeguards, secure onboarding, continuous monitoring and controlled exit. Supplier certification and questionnaires are evidence sources, not guarantees. Effective cyber governance combines technical safeguards, legal analysis, accountable decision-making, ethical consideration and tested operational practice.

Key Terms

Asset: Something valuable that requires protection.

Control: A measure that modifies cyber risk.

Cyber event: An observable occurrence involving an information system.

Cyber incident: An event that compromises or may compromise security or violates policy.

Confidentiality: Protection against unauthorised access or disclosure.

Integrity: Accuracy, completeness and trustworthiness of information and systems.

Availability: Accessibility of systems and information when authorised users need them.

Threat: A potential cause of harm.

Vulnerability: A weakness that may be exploited or triggered.

Inherent risk: Risk before controls are considered.

Residual risk: Risk remaining after controls are applied.

Risk owner: Person accountable for managing a specified risk.

Risk treatment: Action taken to avoid, reduce, transfer or accept risk.

ISMS: Information security management system.

NIST CSF: A framework organising cybersecurity outcomes into six Functions.

Due diligence: Investigation conducted before and during a business relationship.

Subprocessor: A supplier engaged by a primary service provider to process data or perform services.

Compensating control: An alternative control used when the preferred control is impractical.

Supply-chain risk: Risk arising from dependencies on suppliers and their providers.

Review Questions

Short Answer Questions

1. Define inherent risk and residual risk.
2. What are the three elements of the CIA triad?
3. State two purposes of a third-party contract's incident clause.
4. What are the six Functions of the NIST CSF 2.0?
5. Why should a certification's scope be examined during vendor due diligence?

Long Answer Questions

1. Explain a complete basic cyber-risk assessment process from scoping through risk treatment.
2. Compare the roles of ISO/IEC 27001 and the NIST CSF.
3. Explain how preventive, detective, corrective, recovery and compensating controls may work together.
4. Discuss the relationship between legal compliance, ethical responsibility and cybersecurity frameworks.
5. Describe a third-party compliance lifecycle, including onboarding, monitoring and termination.

Analytical / Application Questions

1. A payment processor has privileged access to customer data, but its assurance report excludes the service used by your organisation. Identify the risks and recommend due-diligence actions.
2. A university rates the likelihood of a ransomware incident as 4 and its impact as 4. Calculate the screening score and explain why the result should not be treated as a precise probability.
3. A cloud supplier refuses contractual audit rights but offers an independent assurance report. Evaluate what additional evidence and safeguards should be considered before accepting the residual risk.

Multiple Choice Questions with Answers

Question 1

Which statement best describes residual risk?

A. Risk before any controls are considered

B. Risk remaining after controls are implemented

C. Risk transferred to an insurance company and therefore eliminated

D. Risk that has already caused an incident

Correct Answer: B. Risk remaining after controls are implemented

Question 2

An organisation rates a scenario's likelihood as 4 and impact as 3 using its stated 1–5 screening scales. What is the risk score?

A. 7

B. 9

C. 12

D. 15

Correct Answer: C. 12

Question 3

Which NIST CSF Function focuses most directly on restoring capabilities after a cyber incident?

A. Govern

B. Protect

C. Respond

D. Recover

Correct Answer: D. Recover

Question 4

Why is a vendor's certification scope important?

A. It proves that every possible cyber risk is eliminated

B. It shows whether the assurance applies to the service and activities being purchased

C. It removes the need for a contract

D. It guarantees that the vendor cannot use subcontractors

Correct Answer: B. It shows whether the assurance applies to the service and activities being purchased

Question 5

Which is primarily a detective control?

A. Multi-factor authentication

B. Network segmentation

C. Security log monitoring

D. Data deletion after contract termination

Correct Answer: C. Security log monitoring

Question 6

Which action is part of vendor offboarding?

A. Increasing supplier privileges indefinitely

B. Revoking access and obtaining evidence of secure data deletion

C. Ignoring subcontractors after contract signature

D. Replacing all legal obligations with a questionnaire

Correct Answer: B. Revoking access and obtaining evidence of secure data deletion

Question 7

What is the main limitation of multiplying likelihood and impact scores?

A. It cannot produce a prioritisation value

B. It is always a monetary loss calculation

C. It can create false precision because ordinal scores are not necessarily probabilities

D. It can only be used for physical safety risks

Correct Answer: C. It can create false precision because ordinal scores are not necessarily probabilities

Question 8

Which statement about risk transfer is correct?

A. A contract or insurance policy always removes statutory duties

B. Risk transfer can allocate costs while legal and ethical responsibilities may remain

C. Risk transfer means no controls are required

D. Risk transfer is the same as risk avoidance

Correct Answer: B. Risk transfer can allocate costs while legal and ethical responsibilities may remain

Question 9

What should a supplier incident clause normally specify?

A. Only the supplier's marketing description

B. Reporting channel, timing, required information and cooperation duties

C. That incidents must never be reported to regulators

D. That all evidence should be destroyed after notification

Correct Answer: B. Reporting channel, timing, required information and cooperation duties

Question 10

Which statement most accurately distinguishes ISO/IEC 27001 from the NIST CSF?

A. ISO/IEC 27001 provides an ISMS requirements structure, while NIST CSF organises cybersecurity outcomes

B. NIST CSF is a criminal statute, while ISO/IEC 27001 is a court judgment

C. ISO/IEC 27001 applies only to physical security, while NIST CSF applies only to privacy

D. They are identical legal compliance schemes

Correct Answer: A. ISO/IEC 27001 provides an ISMS requirements structure, while NIST CSF organises cybersecurity outcomes