Security Assurance, Strategy and Emerging Developments

Introduction

Cyber security is no longer only a technical function concerned with firewalls, malware and access controls. It is an assurance and governance discipline that helps an organisation understand whether its information, services, people and technology can withstand disruption and recover safely. Security assurance provides justified confidence that controls are appropriately designed, implemented and operating effectively. Security strategy converts organisational objectives and risk tolerance into priorities, investment decisions, accountability and measurable improvement.

This chapter examines vulnerability management, penetration-testing oversight, control testing, supplier and supply-chain assurance, security roadmaps, budgets, metrics and awareness programmes. It then evaluates ransomware, artificial-intelligence-enabled attacks, quantum-related risks and evolving regulation. The emphasis is strategic: security professionals must be able to interpret evidence, challenge assumptions, communicate risk to decision-makers and coordinate technical and business responses.

Learning Objectives

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

1. Explain the purpose and lifecycle of security assurance.
2. Design a risk-based vulnerability-management and penetration-testing programme.
3. Evaluate control effectiveness and interpret assurance evidence.
4. Assess suppliers, cloud providers and software supply chains.
5. Develop a security roadmap, budget, metrics and awareness programme.
6. Analyse ransomware, AI-enabled attacks and quantum risks.
7. Relate security decisions to ethics, governance and changing regulation.

1. Security Assurance as a Management Discipline

Security assurance is the systematic collection and evaluation of evidence to determine whether security objectives and controls are suitable, implemented and effective. It differs from security operations. Operations performs activities such as monitoring and incident response; assurance examines whether those activities are adequately designed and consistently performed.

A useful assurance chain is:

Objective → Risk → Control → Evidence → Evaluation → Remediation → Reassessment

For example, an organisation may have the objective of protecting customer records. The risk may be unauthorised disclosure caused by compromised administrator accounts. Controls may include phishing-resistant multi-factor authentication, privileged-access management and access reviews. Evidence may include configuration records, authentication logs and review approvals. Assurance evaluates whether the controls address the risk and whether they work in practice.

1.1 Design effectiveness and operating effectiveness

A control is design-effective when it is capable of addressing the relevant risk. It is operating-effective when it operates as intended over the period being examined.

A quarterly access review may be design-effective because it can identify inappropriate access. It is not operating-effective if reviews are frequently late, reviewers lack sufficient information or identified exceptions are never removed. Conversely, a control may operate consistently but be poorly designed—for example, a password policy that requires frequent changes but does not prevent password reuse or phishing.

1.2 Assurance sources

Assurance evidence can come from several sources:

• internal audits and control self-assessments;
• vulnerability scans and penetration tests;
• security monitoring and incident records;
• configuration and change-management data;
• independent certification or attestation reports;
• supplier questionnaires and contract reviews;
• disaster-recovery and business-continuity exercises;
• interviews, observation and sampling.

Evidence should be relevant, reliable, sufficient and current. A supplier’s marketing statement is weak evidence compared with an independent assurance report whose scope, testing period and exceptions are clearly described.

2. Risk-Based Vulnerability Management

A vulnerability is a weakness that can be exploited or otherwise contribute to harm. Vulnerability management is the continuing process of discovering, validating, prioritising, treating and verifying vulnerabilities. It is not equivalent to running a scanner.

A mature lifecycle contains the following stages:

1. Asset discovery: maintain an inventory of hardware, software, identities, cloud resources, APIs and data stores.
2. Assessment: use authenticated scanning, configuration review, code analysis, threat intelligence and supplier information.
3. Validation: remove false positives and confirm whether a finding is exploitable or materially exposed.
4. Prioritisation: consider severity, exploitability, exposure, asset criticality, business impact and compensating controls.
5. Treatment: patch, upgrade, reconfigure, isolate, remove, monitor or formally accept the risk.
6. Verification: rescan or retest to confirm remediation.
7. Reporting and learning: analyse trends, recurring causes and management accountability.

2.1 Prioritisation rather than severity alone

A high severity score does not automatically make a vulnerability the organisation’s most urgent problem. A medium-severity weakness on an internet-facing payment system may be more important than a critical weakness on an isolated, obsolete test server. Prioritisation should combine technical and contextual evidence.

One practical model is a qualitative matrix using:

• likelihood of exploitation;
• exposure and accessibility;
• asset and data criticality;
• availability of public exploit code;
• evidence of exploitation in the sector;
• effectiveness of existing controls;
• time required to remediate.

Where numerical scoring is used, the result should support judgement rather than replace it. A simple risk estimate can be expressed as:

Likelihood and impact may be ordinal categories, such as 1–5, rather than precise probabilities. The calculation is therefore a prioritisation aid, not a claim that risk has been measured with scientific precision. Organisations must define category meanings consistently; otherwise a score of 12 in one team may not be comparable with 12 in another.

2.2 Vulnerability-management governance

A policy should define asset ownership, scanning frequency, severity thresholds, remediation timeframes, exception approval, evidence requirements and escalation. Exceptions should have an owner, business justification, expiry date and compensating controls. “Accepted indefinitely” is normally a sign of unmanaged risk.

Common weaknesses include incomplete asset inventories, unauthenticated scans, unsupported systems, patching without testing, and reporting only the number of vulnerabilities. Better reporting describes exposure, age, business criticality, overdue remediation and recurring root causes.

3. Penetration-Testing Oversight

A penetration test is an authorised, controlled attempt to identify and demonstrate exploitable weaknesses. It differs from vulnerability scanning because testers use human reasoning, chaining, validation and business-context analysis. It also differs from a red-team exercise, which generally pursues broader objectives such as testing detection, response and organisational resilience over an extended period.

3.1 Scope and rules of engagement

Before testing begins, the organisation should approve:

• objectives and success criteria;
• in-scope and out-of-scope systems;
• permitted techniques and prohibited actions;
• test windows and emergency contacts;
• treatment of personal or sensitive data;
• authentication accounts and test data;
• evidence-handling and retention rules;
• third-party permissions;
• stop conditions and incident-escalation procedures.

Testing without permission can be unlawful and can disrupt services. Written authorisation must cover systems owned by, or operated through, suppliers. Cloud testing must comply with provider requirements and contractual conditions.

3.2 Selecting and managing testers

Independence, competence and methodology matter. The organisation should examine tester experience, relevant certifications where useful, references, conflicts of interest, insurance, data-handling arrangements and reporting quality. The cheapest test is not necessarily the best value if its scope is narrow or findings are poorly evidenced.

A quality report normally includes an executive risk summary, scope and limitations, methodology, reproducible findings, affected assets, business impact, technical evidence, severity rationale, remediation advice and a retest statement. Management should not treat a clean report as proof that no vulnerabilities exist. It means that none were identified under the stated scope, methods and time constraints.

4. Control Testing and Assurance Evaluation

Control testing determines whether controls are suitably designed and operating as intended. Testing methods include inquiry, inspection, observation, reperformance and technical testing. Inquiry alone is usually weak because a person’s description of a process does not prove that it occurs consistently.

A test should specify:

• control objective;
• control owner;
• population and period;
• testing method;
• sample-selection method;
• expected evidence;
• exceptions and their significance;
• conclusion and remediation action.

4.1 Sampling and evidence

If a control operates monthly for a year, the tester may examine a defined sample of monthly records, selected using a documented rationale. Sampling cannot provide absolute certainty unless the entire population is examined. The conclusion should therefore state the population, sample and limitations.

Evidence should be protected against alteration and linked to the control period. For example, a screenshot taken after an audit may show a current configuration but not prove that the setting was enabled during the period under review. Logs, change records and independently generated reports may provide stronger historical evidence.

4.2 Findings and root causes

Findings should distinguish condition, criterion, cause, effect and recommendation:

• Condition: what was observed.
• Criterion: what should have occurred.
• Cause: why the deviation occurred.
• Effect: actual or potential consequence.
• Recommendation: proportionate corrective action.

A recurring failure to patch may be caused not by careless technicians but by unsupported applications, unclear ownership, inadequate testing environments or conflicting availability targets. Treating the symptom alone produces repeated findings.

5. Supplier and Supply-Chain Assurance

Organisations inherit risk from suppliers, contractors, cloud services, managed-service providers, open-source components and software-build pipelines. Supply-chain assurance is a lifecycle, not a questionnaire completed once during procurement.

5.1 Due diligence and tiering

Suppliers should be classified according to factors such as access to sensitive data, service criticality, connectivity, concentration risk, substitutability and recovery requirements. A payroll provider and a stationery supplier should not receive identical scrutiny.

Due diligence may include:

• security governance and policy maturity;
• identity and privileged-access controls;
• encryption and key management;
• vulnerability and patch management;
• incident notification and cooperation;
• resilience, backup and recovery evidence;
• subcontractor and fourth-party oversight;
• data location and legal processing conditions;
• secure development and software provenance;
• independent assurance reports and exceptions.

5.2 Contractual controls

Contracts should define security responsibilities, minimum controls, audit or assurance rights, breach notification, evidence access, data-return and deletion requirements, subcontractor approval, continuity obligations, service-level expectations and termination assistance. Responsibility matrices should clarify which party secures the cloud service, operating system, application, identity layer and data.

A supplier certificate is not a substitute for risk analysis. The organisation must determine whether the certificate covers the relevant service, location, time period and control objectives.

5.3 Software supply-chain security

Important practices include dependency inventories, software bills of materials where appropriate, signed releases, protected build systems, code review, secret management, provenance controls, vulnerability disclosure processes and rapid revocation capability. Open-source software is valuable but requires governance: a component may be widely used yet unmaintained, vulnerable or subject to licence obligations.

6. Security Strategy, Roadmaps and Budgets

Security strategy should begin with organisational outcomes rather than a list of products. It should explain the current risk position, target state, priorities, dependencies, ownership, resources and measures of success.

A strategy-development process may include:

1. understand business services, legal duties and risk appetite;
2. establish the current capability baseline;
3. identify material gaps and threat scenarios;
4. define a target operating model;
5. rank initiatives by risk reduction, feasibility and dependency;
6. assign owners, funding and milestones;
7. establish measures and governance reviews.

6.1 Roadmap design

A roadmap should show sequencing. Foundational identity, asset inventory, logging and backup improvements may be prerequisites for more advanced analytics. Initiatives can be grouped into immediate stabilisation, medium-term capability and long-term transformation. Each initiative should have a measurable outcome, not merely a technology name.

For example, “deploy endpoint software” is an activity. “Ensure 98% of supported endpoints report current protection status within 24 hours” is an outcome, subject to a defined measurement method.

6.2 Budgeting and business cases

A security budget may include personnel, managed services, licences, testing, training, architecture, resilience, legal support and contingency. A business case should explain the risk addressed, options considered, implementation costs, ongoing costs, dependencies, expected benefits and consequences of deferral.

Security benefits are often risk reduction rather than revenue. Avoid claiming that a control will prevent all incidents. A defensible case states assumptions and uncertainty, and connects the investment to service continuity, legal obligations, customer trust and operational resilience.

7. Metrics and Awareness Programmes

Metrics should support decisions. A useful distinction is:

• activity measures: what was done, such as number of scans;
• coverage measures: what proportion is included, such as percentage of assets inventoried;
• quality measures: how well it was done, such as validated finding accuracy;
• outcome measures: whether exposure or harm is reducing, such as recurring critical exposure or recovery performance.

Examples include patching time by asset criticality, percentage of privileged accounts using phishing-resistant authentication, mean time to contain incidents, backup restoration success, overdue supplier reviews and completion of remediation actions. Metrics should include definitions, data sources, owner, frequency and limitations.

Averages can conceal extreme delays. Percentiles, ageing bands and trend analysis may provide a more realistic picture. Metrics must not create harmful incentives—for example, rewarding teams for closing findings without validating remediation.

Awareness programmes should be role-based and continuous. General staff need practical guidance on reporting suspicious messages, protecting credentials and handling data. Developers need secure design and dependency-management training; administrators need privileged-access and recovery training; executives need decision-making exercises. Effectiveness should be evaluated through reporting behaviour, exercise performance, knowledge checks and incident learning—not merely attendance.

8. Ransomware and Organisational Resilience

Ransomware combines unauthorised access, data encryption, extortion and sometimes theft or disruption. Effective defence is layered: strong identity controls, vulnerability reduction, network segmentation, endpoint protection, tested backups, immutable or offline recovery copies, privileged-access restrictions, monitoring and rehearsed response.

A backup is not proven until restoration is tested. Recovery planning should define recovery time objectives and recovery point objectives. The recovery time objective is the targeted maximum time to restore a service after disruption. The recovery point objective is the targeted maximum amount of data loss measured in time. Both are service-specific and should be agreed with business owners.

Incident response must address technical containment, legal and regulatory obligations, communications, evidence preservation, supplier coordination and safe recovery. Payment decisions involve legal, ethical, operational and law-enforcement considerations; payment does not guarantee deletion of stolen data or restoration of access.

9. Artificial Intelligence and Cyber Security

AI can assist defenders with alert triage, summarisation, anomaly analysis, code review and exercise generation. It can also support attackers through convincing social engineering, automated reconnaissance, malware adaptation, deepfakes and rapid production of malicious content. The strategic question is not whether AI is good or bad, but how its use changes capability, scale, speed and accountability.

Controls for organisational AI use should include approved-use policies, data classification, privacy review, access control, supplier assessment, prompt and output handling, human review, testing for bias and unsafe behaviour, logging and incident procedures. Sensitive information should not be entered into an unapproved public model. AI-generated code and advice require verification because models can produce insecure, inaccurate or fabricated outputs.

AI-enabled attacks also increase the importance of resilient identity verification, out-of-band confirmation for high-risk requests, detection engineering and staff training that addresses voice and video impersonation. Defensive AI should be evaluated against false positives, false negatives, explainability, data quality and adversarial manipulation.

10. Quantum Risk and Cryptographic Transition

Large-scale fault-tolerant quantum computers could threaten widely used public-key cryptography based on integer factorisation or discrete logarithms. Symmetric cryptography is affected differently; larger key sizes can generally provide a mitigation, subject to algorithm and implementation choices.

The immediate strategic concern is “harvest now, decrypt later”: adversaries may collect encrypted data today for possible future decryption. Organisations should identify long-lived sensitive information, inventory cryptographic dependencies, determine where public-key algorithms are used, require cryptographic agility and monitor standards and migration guidance.

Migration should be risk-based. Priorities include data with long confidentiality lifetimes, externally exposed systems, certificates and identity infrastructure, embedded devices with long replacement cycles, and suppliers whose cryptographic dependencies are unclear. Organisations should avoid adopting unreviewed algorithms merely because they are described as quantum-safe; standardisation, implementation maturity and interoperability matter.

11. Regulation, Ethics and Governance

Regulation increasingly requires risk management, breach handling, privacy protection, resilience, supply-chain oversight and accountability. Exact obligations vary by jurisdiction and sector, so professionals must consult current authoritative sources rather than rely on old summaries. Compliance is a baseline, not proof of security.

Ethical security practice requires authorised testing, proportionality, privacy protection, responsible disclosure, avoidance of unnecessary harm and honest communication of uncertainty. Security controls can themselves create risks: excessive monitoring may undermine privacy; aggressive fraud controls may exclude legitimate users; biometric systems may produce unequal impacts; and employee surveillance may damage trust.

Boards and senior leaders should receive risk information in business terms while retaining access to technically meaningful evidence. Clear accountability is essential: a security function may advise and monitor, but service owners remain responsible for the risks created by their systems.

12. Illustrative Case: Northbridge Health Services

Background

Northbridge Health Services, a fictional regional healthcare provider, operates hospitals, clinics and a patient portal. It relies on a cloud-hosted electronic-record platform and several medical-device suppliers. An internal review found an incomplete asset inventory, inconsistent multifactor authentication and backups that had never undergone a full restoration test.

Problem

A critical vulnerability was announced in an internet-facing appliance used at several sites. The vulnerability-management dashboard listed 40 affected devices, but the infrastructure team could identify only 31. A supplier also disclosed that a subcontractor had experienced a ransomware incident. Executives were concerned about patient safety, regulatory reporting and service continuity.

Analysis

The security team verified the vulnerability using authenticated assessment and asset-discovery data. The nine unaccounted devices were treated as a high-priority inventory risk. The affected appliance supported clinical services, so immediate isolation and compensating controls were considered alongside patching. Supplier contracts were reviewed for notification, evidence and recovery obligations. The backup team discovered that successful backup jobs did not prove that clinical databases could be restored within agreed service requirements.

Approach and solution

Northbridge authorised emergency remediation, restricted management interfaces, enabled phishing-resistant authentication for administrators and established daily executive reporting until exposure was reduced. It required the supplier to provide incident facts, affected-service analysis and evidence of containment. A recovery exercise restored a representative clinical service into an isolated environment, revealing that a key identity dependency had not been documented.

The twelve-month roadmap then prioritised asset inventory, privileged-access management, tested recovery, supplier tiering, vulnerability remediation ownership and role-based awareness. Metrics included percentage of clinical assets with verified owners, critical exposure age, restoration-test success and supplier actions overdue.

Outcome

The appliance exposure was remediated, the nine unknown devices were identified, and the recovery process was redesigned. The organisation did not claim that risk had been eliminated. Instead, it documented residual risks, owners, deadlines and evidence requirements. The board approved funding because the programme connected technical weaknesses to patient-care continuity and regulatory accountability.

Learning points

1. Asset visibility is a prerequisite for credible vulnerability management.
2. Supplier risk must be assessed as part of service risk.
3. Backup completion is not the same as recovery capability.
4. Emergency action and long-term capability development must operate together.
5. Clear metrics improve governance when they describe exposure and outcomes rather than activity alone.

Challenges and Limitations

Security assurance is constrained by incomplete evidence, changing environments, supplier opacity, limited testing windows and uncertain threat information. A test provides evidence about a defined scope, not a universal guarantee. Quantitative risk scores may create false precision. Compliance frameworks can encourage checklist behaviour. Metrics can be gamed, and awareness training can become ceremonial if it is not connected to job tasks and observed behaviour.

Professionals should therefore triangulate evidence, record assumptions, preserve independence, review changing context and communicate uncertainty. Assurance is strongest when it is continuous, risk-based and connected to operational decisions.

Best-Practice Checklist

• Maintain an authoritative, owner-validated asset and service inventory.
• Prioritise vulnerabilities using exposure, exploitability and business impact.
• Authorise penetration tests with explicit scope and stop conditions.
• Test both control design and operating effectiveness.
• Tier suppliers and include enforceable security and continuity terms.
• Build roadmaps around outcomes, dependencies and accountable owners.
• Use metrics that reveal exposure, quality and improvement.
• Test restoration, not merely backup completion.
• Govern AI use through data protection, human review and accountability.
• Begin cryptographic inventory and migration planning before quantum capability becomes an emergency.
• Treat compliance as a foundation for risk management, not its conclusion.

Chapter Summary

Security assurance provides evidence-based confidence that security objectives and controls are appropriate and effective. Vulnerability management requires accurate asset knowledge, contextual prioritisation, treatment and verification. Penetration testing must be authorised, scoped and independently evaluated. Control testing examines both design and operation, while supplier assurance extends security governance across cloud, software and service dependencies.

A security strategy connects business objectives, risk appetite, capability gaps, investment and measurable outcomes. Roadmaps should sequence foundational capabilities, budgets should explain risk and value, and metrics should reveal exposure and improvement rather than merely activity. Awareness programmes are most effective when role-based and evaluated through behaviour.

Ransomware demonstrates the importance of identity protection, segmentation, monitoring and tested recovery. AI changes both attack and defence capabilities and requires governance over data, outputs and human accountability. Quantum risk requires cryptographic inventory, agility and long-term migration planning. Across all these areas, ethical practice, regulatory awareness, transparent uncertainty and accountable governance are essential.

Key Terms

Security assurance: The systematic evaluation of evidence to provide confidence that security objectives and controls are effective.

Design effectiveness: The extent to which a control is capable of addressing its intended risk.

Operating effectiveness: The extent to which a control operates consistently as designed.

Vulnerability management: The lifecycle of discovering, prioritising, treating and verifying security weaknesses.

Penetration test: An authorised attempt to identify and demonstrate exploitable weaknesses.

Rules of engagement: The approved boundaries, methods, permissions and safety conditions for a security test.

Control objective: The security result a control is intended to achieve.

Compensating control: An alternative measure that reduces risk when the preferred control is unavailable.

Supply-chain risk: Risk introduced through suppliers, contractors, software or service dependencies.

Software bill of materials: An inventory of components contained in a software product.

Security roadmap: A sequenced plan for reaching a defined security capability target state.

Risk appetite: The amount and type of risk an organisation is willing to pursue or retain.

Recovery time objective: The targeted maximum time for restoring a service after disruption.

Recovery point objective: The targeted maximum period of data loss measured in time.

Ransomware: Malware or an extortion operation that denies access to data or services, often combined with data theft.

Cryptographic agility: The ability to change cryptographic algorithms and implementations without disproportionate disruption.

Harvest now, decrypt later: Collection of encrypted data today for possible decryption using future capabilities.

Security metric: A defined measure used to evaluate security activity, exposure, quality or outcomes.

Residual risk: Risk remaining after controls and treatments have been applied.

Review Questions

Short Answer Questions

1. Distinguish design effectiveness from operating effectiveness.
2. Why is asset inventory important to vulnerability management?
3. State two matters that should be included in penetration-test rules of engagement.
4. What is the difference between a recovery time objective and a recovery point objective?
5. Why is a supplier certificate not sufficient by itself to establish security assurance?

Long Answer Questions

1. Explain a complete, risk-based vulnerability-management lifecycle and discuss common implementation weaknesses.
2. Describe how an organisation should plan, authorise, manage and evaluate a penetration test.
3. Explain how security objectives, risk appetite, capability gaps and investment decisions are connected in a security roadmap.
4. Discuss how metrics and awareness programmes can improve security while avoiding harmful incentives.
5. Evaluate the strategic implications of ransomware, AI-enabled attacks and quantum-related cryptographic risk.

Analytical / Application Questions

1. An internet-facing server has a medium technical severity score but supports a critical payment service, while an isolated test server has a critical score. Explain which should be prioritised and what additional evidence you would collect.
2. A cloud supplier reports that it has passed an independent audit, but the report excludes the customer’s region and does not cover incident response. Assess the assurance gap and recommend actions.
3. Design a twelve-month security roadmap for an organisation with unknown assets, untested backups, weak privileged access and limited budget. Justify the sequence of initiatives.

Multiple Choice Questions with Answers

Question 1

Which statement best describes operating effectiveness?

A. The control is capable of addressing a risk in theory

B. The control operates consistently as designed during the relevant period

C. The control has been mentioned in a security policy

D. The control has received the lowest implementation cost

Correct Answer: B. The control operates consistently as designed during the relevant period

Question 2

Which activity is part of vulnerability verification?

A. Deleting all scan results

B. Rescanning or retesting after remediation

C. Increasing the number of policy documents

D. Replacing every supplier

Correct Answer: B. Rescanning or retesting after remediation

Question 3

What is the primary purpose of rules of engagement for a penetration test?

A. To define authorised scope, methods and safety conditions

B. To guarantee that no vulnerability exists after testing

C. To replace incident-response procedures

D. To conceal findings from system owners

Correct Answer: A. To define authorised scope, methods and safety conditions

Question 4

Which is the strongest example of an outcome-oriented security metric?

A. Number of security meetings held

B. Number of pages in the security policy

C. Percentage of critical assets with verified owners

D. Number of slides used in training

Correct Answer: C. Percentage of critical assets with verified owners

Question 5

What does a recovery point objective describe?

A. The maximum acceptable time to restore a service

B. The targeted maximum period of data loss measured in time

C. The number of employees in a recovery team

D. The time required to complete a penetration test

Correct Answer: B. The targeted maximum period of data loss measured in time

Question 6

Why should suppliers be tiered?

A. To give every supplier identical security requirements

B. To focus assurance effort according to criticality and exposure

C. To eliminate the need for contracts

D. To ensure suppliers cannot use subcontractors

Correct Answer: B. To focus assurance effort according to criticality and exposure

Question 7

Which practice is most appropriate for organisational use of generative AI?

A. Entering confidential data into any public model

B. Accepting AI-generated code without review

C. Applying approved-use rules, data controls and human verification

D. Removing all logging to protect model privacy

Correct Answer: C. Applying approved-use rules, data controls and human verification

Question 8

What is the strategic meaning of cryptographic agility?

A. The ability to change cryptographic mechanisms without disproportionate disruption

B. The ability to increase network bandwidth automatically

C. The replacement of all passwords with biometrics

D. The use of one permanent encryption algorithm

Correct Answer: A. The ability to change cryptographic mechanisms without disproportionate disruption

Question 9

Which statement about backups is most accurate?

A. A successful backup job proves recovery capability

B. Backups are unnecessary if antivirus is installed

C. Restoration tests are needed to demonstrate recovery capability

D. Only suppliers need to test restoration

Correct Answer: C. Restoration tests are needed to demonstrate recovery capability

Question 10

Which action best reflects ethical penetration testing?

A. Testing third-party systems without permission

B. Collecting unnecessary personal data for publicity

C. Operating within written authorisation and agreed stop conditions

D. Publishing exploitable details before remediation

Correct Answer: C. Operating within written authorisation and agreed stop conditions