Governance, Compliance and Ethical Security Practice

Introduction and Context

Blockchain systems are often described as trust-minimising technologies, but they do not eliminate the need for governance. They redistribute trust among software developers, node operators, validators, custodians, exchanges, users, auditors and regulators. A technically secure protocol can still create legal, operational and ethical risk if access rights are poorly assigned, personal data are written permanently to a ledger, suspicious transactions are ignored, or a vulnerability is disclosed irresponsibly.

Governance and compliance therefore form part of blockchain security rather than an administrative activity added after deployment. Governance determines who may make decisions, change code, approve transactions, respond to incidents and accept risk. Compliance translates legal and regulatory duties into controls, evidence and accountable processes. Ethical security practice establishes boundaries for testing, monitoring, disclosure and use of information.

This chapter presents a practical framework for security policies, control ownership, audits, segregation of duties, third-party assurance, privacy, anti-money-laundering (AML), sanctions, cybersecurity requirements, responsible disclosure, ethical hacking, surveillance and immutable data. Specific legal obligations vary by jurisdiction, sector and business model; organisations must therefore obtain current legal and regulatory advice rather than treating this chapter as legal advice.

Learning Objectives

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

1. Explain the role of governance, policies and control ownership in blockchain security.
2. Distinguish first-party controls, independent audits and third-party assurance.
3. Apply segregation-of-duties principles to wallets, smart contracts and operational administration.
4. Relate blockchain operations to privacy, AML, sanctions and cybersecurity obligations.
5. Design a responsible vulnerability-disclosure and ethical-hacking process.
6. Evaluate the ethical consequences of surveillance and permanently recorded data.
7. Recommend practical governance improvements for a blockchain-based organisation.

1. Governance as a Security Control

Governance is the system by which an organisation directs, controls and reviews its activities. In a blockchain enterprise, governance exists at several layers:

• Protocol governance: decisions about software upgrades, consensus rules, validator participation and emergency changes.
• Organisational governance: decisions by boards, executives, risk committees and control owners.
• Operational governance: procedures for key management, transaction approval, incident response and business continuity.
• Ecosystem governance: relationships with custodians, exchanges, cloud providers, oracle operators, auditors and other participants.
• Regulatory governance: processes that demonstrate compliance with applicable law and supervisory expectations.

A blockchain network may be decentralised in its technical architecture while the surrounding service is highly centralised. For example, a decentralised ledger may be accessed through one exchange, controlled by one custodian or governed by a small group of administrators. Governance must therefore examine the complete service, not merely the consensus mechanism.

A useful governance question is: who can cause which outcome, under what authority, using which evidence, and subject to whose review? This question reveals hidden privileges. A developer who can modify a smart contract, approve a release and control the deployment key represents a concentration of power even if the blockchain itself has many independent nodes.

Policies, standards, procedures and guidelines

These terms should not be confused:

A sound policy is approved by an authorised body, assigned an owner, communicated to relevant personnel, reviewed periodically and supported by measurable controls. A policy that says “protect keys securely” is too vague to audit. A stronger policy specifies key generation, storage, backup, recovery, approval, rotation, monitoring and destruction requirements.

2. Control Frameworks and Ownership

A control is a measure designed to prevent, detect or correct an unwanted event. Controls may be:

• Preventive: hardware security modules, access restrictions and transaction limits.
• Detective: anomaly monitoring, log review and reconciliation.
• Corrective: incident response, key revocation and recovery procedures.
• Directive: policies, training and governance mandates.
• Compensating: alternative measures used when a preferred control cannot be implemented.

Controls may also be classified as administrative, technical or physical. Blockchain-specific examples include an approval committee for administrative control, a multisignature wallet for technical control and restricted access to a signing room for physical control.

Control ownership

Control ownership is accountability for ensuring that a control is properly designed, implemented, operated and improved. Ownership does not necessarily mean personally performing every task. A treasury manager may own the control requiring dual approval for transfers, while an operations team performs the approvals and an internal audit team tests whether the control works.

A practical control register should include:

The distinction between design effectiveness and operating effectiveness is important. A control is design-effective if it would address the stated risk when properly performed. It is operating-effective if it actually operated consistently during the relevant period and produced reliable evidence.

Risk-based governance

Not every asset requires identical controls. A risk assessment considers the value at risk, threat likelihood, potential impact, legal obligations, system complexity and recovery capability. High-value treasury wallets may require offline storage, geographic separation, multiple approvers and transaction simulation. A low-value development wallet may use less stringent measures, provided it cannot access production assets.

Risk acceptance must be explicit. It should identify the risk, business rationale, compensating controls, responsible approver, expiry or review date and conditions for reassessment. “No known issue” is not the same as “risk accepted by an authorised decision-maker.”

3. Segregation of Duties and Privileged Access

Segregation of duties (SoD) prevents one person from controlling incompatible stages of a sensitive process. It reduces fraud, error and abuse by requiring collusion or independent detection before a harmful action succeeds.

For a digital-asset operation, incompatible duties may include:

• writing and approving smart-contract code;
• creating and approving a production deployment;
• requesting and authorising a treasury transfer;
• administering a wallet and reviewing its audit logs;
• changing transaction limits and approving transactions under those limits;
• onboarding a customer and independently approving high-risk activity;
• investigating an alert and closing it without review.

SoD does not require every action to involve a different individual. In a small organisation, compensating controls can include board-level review, time delays, immutable logging, independent reconciliation, external monitoring or threshold signatures.

Multisignature approval

A multisignature wallet can enforce an approval threshold. In an m-of-n arrangement, n authorised keys exist and at least m distinct signatures are required for a transaction. For example, a 2-of-3 wallet requires two of three designated signers. This reduces dependence on one key but does not automatically ensure independence: three keys controlled by the same person or stored in the same environment provide weak practical separation.

Good practice includes:

1. documenting signer roles and independence;
2. using separate devices and authentication factors;
3. applying transaction limits and allowlists;
4. simulating transactions before signing;
5. recording the business purpose and approvals;
6. reviewing signer membership periodically;
7. maintaining an emergency recovery process;
8. testing recovery without exposing production secrets.

Privileged access management

Privileged accounts should be unique, strongly authenticated, time-limited where possible and monitored. Access should follow least privilege and be removed promptly when roles change. Break-glass access may be necessary during an incident, but it should require a documented reason, enhanced logging and retrospective review.

4. Audits and Third-Party Assurance

An audit is a systematic, evidence-based evaluation against defined criteria. It is not a guarantee that no vulnerability exists. Audit scope, criteria, sampling, period and limitations determine the meaning of an audit conclusion.

Types of assurance

• Internal audit: independent within the organisation, reporting to an appropriate governance body such as an audit committee.
• External financial or compliance audit: performed by an independent professional organisation against specified criteria.
• Smart-contract audit: technical review of code, architecture, assumptions and known vulnerability classes.
• Penetration test: controlled attempt to identify exploitable weaknesses within an agreed scope.
• Certification or attestation: formal statement that specified controls or management systems meet a defined standard or framework.
• Service-organisation assurance: evidence about a provider whose services affect the customer’s control environment.

A smart-contract audit is not equivalent to a financial audit, and a penetration test is not equivalent to continuous security monitoring. Organisations should ask what was tested, what was excluded, which version was examined, how findings were prioritised, whether remediation was verified and whether changes occurred after testing.

Audit lifecycle

A defensible audit process generally involves:

1. defining objectives, scope, criteria and materiality;
2. identifying risks and control assertions;
3. collecting reliable evidence;
4. testing design and operation;
5. recording exceptions and management responses;
6. agreeing remediation owners and deadlines;
7. validating closure;
8. reporting residual risk to accountable governance bodies.

Evidence may include access logs, approval records, deployment hashes, code-review records, incident tickets, training records, reconciliation reports and configuration snapshots. Screenshots alone may be incomplete because they can omit context and timestamps.

Third-party assurance

Blockchain organisations commonly rely on cloud infrastructure, custodians, node providers, analytics companies, identity vendors, oracle services and external developers. A third-party assurance programme should classify suppliers by criticality and assess:

• service scope and data handled;
• location and legal dependencies;
• key-management responsibilities;
• subcontractors and concentration risk;
• incident-notification obligations;
• recovery objectives and testing;
• audit rights and assurance reports;
• exit, portability and termination arrangements.

A supplier’s assurance report is evidence, not a substitute for the customer’s own risk assessment. The customer must determine whether the report covers the relevant service, period, controls and complementary customer controls.

5. Privacy and Immutable Ledgers

Blockchains create a difficult relationship between transparency and privacy. A public ledger may expose addresses, transaction amounts, timing and behavioural patterns. Although an address is not necessarily a name, it can become identifiable when linked with exchange records, IP data, device information, public statements or repeated transaction patterns.

Privacy risk is therefore not limited to putting a person’s name directly on-chain. It includes inference, linkage and re-identification. Public visibility can reveal salary payments, supplier relationships, political donations, medical transactions or patterns of movement.

Data minimisation and architecture

A strong design principle is to keep personal and confidential data off-chain whenever possible. The ledger can store a reference, commitment or proof while the underlying data remain in a controlled system. However, a hash is not automatically anonymous. If the input has a small or guessable range, an attacker may test possible inputs and compare hashes. A ledger reference can also remain personal data if it can be linked to an identifiable person.

Privacy-preserving options include:

• storing only necessary transaction metadata;
• using off-chain repositories with access controls;
• encrypting sensitive data, while recognising that key compromise exposes it;
• using selective disclosure credentials;
• applying zero-knowledge proofs where suitable;
• separating identity systems from transaction identifiers;
• establishing retention and deletion procedures for off-chain information.

A key issue is that encryption does not make permanent storage risk-free. Cryptographic algorithms may weaken, keys may be lost or disclosed, and future computing capabilities may alter the threat environment. Organisations should assess whether the ledger stores information that should remain confidential for a long period.

Privacy obligations vary across jurisdictions. Common principles in data-protection regimes include lawfulness, purpose limitation, data minimisation, accuracy, security, transparency and accountability. Rights such as access, correction or erasure can be difficult to reconcile with immutable records. This is an architectural problem, not merely a documentation problem.

6. AML, Counter-Terrorist Financing and Sanctions

Blockchain services that exchange, transfer, custody or facilitate digital assets may fall within financial-crime obligations depending on jurisdiction and activity. AML and counter-terrorist-financing programmes commonly require risk assessment, customer identification, beneficial-owner understanding, transaction monitoring, recordkeeping, escalation and reporting of suspicious activity.

A ledger’s transparency does not itself provide compliance. A public transaction may show that value moved, but not necessarily who controls an address, why the transfer occurred or whether it is connected to a sanctioned person. Conversely, blockchain analytics can produce false positives because address clustering and behavioural inference are probabilistic.

A risk-based compliance process

A practical process includes:

1. Customer and business risk assessment: consider geography, products, customer types, channels and transaction patterns.
2. Customer due diligence: establish identity and, where required, beneficial ownership and purpose of the relationship.
3. Enhanced due diligence: apply additional measures to higher-risk customers, jurisdictions or activities.
4. Transaction monitoring: identify unusual patterns using rules, analytics and human investigation.
5. Sanctions screening: screen relevant persons, entities, addresses and transactions against applicable lists and restrictions.
6. Escalation and reporting: investigate alerts, document decisions and make legally required reports through approved channels.
7. Recordkeeping and training: retain evidence for the legally required period and train relevant staff.

Sanctions compliance is not solved by blocking a single address. Funds can move through intermediaries, smart contracts, bridges and newly created addresses. Controls must consider typologies, exposure, jurisdiction, screening quality, false positives and the organisation’s legal obligations. Blocking or freezing assets also requires careful authority, documentation and customer communication.

Analytics and artificial intelligence can prioritise alerts, identify clusters and detect anomalies, but models can encode bias, generate unexplained results or be manipulated by adversaries. Human review, model validation, data governance and appeal or escalation mechanisms remain necessary.

7. Cybersecurity Requirements and Resilience

Blockchain security must be integrated with conventional cybersecurity. Relevant controls commonly include governance, asset inventory, identity and access management, secure development, vulnerability management, logging, incident response, backup, recovery and supplier risk management. Applicable requirements may derive from national cybersecurity laws, financial-sector rules, privacy legislation, contractual standards or recognised control frameworks.

A blockchain threat model should include more than attacks on consensus. It should consider:

• compromised administrator credentials;
• stolen signing keys;
• malicious or defective smart contracts;
• oracle manipulation;
• bridge compromise;
• vulnerable wallet software;
• denial-of-service attacks;
• insider abuse;
• supply-chain compromise;
• cloud or hosting failure;
• governance-token capture;
• ransomware affecting off-chain systems;
• fraudulent social-engineering requests.

Resilience requires defined recovery priorities. Organisations should know which functions must be restored first, how transactions are reconciled after an outage, who can pause a service, how users are informed and how recovery decisions are authorised. A technically immutable ledger does not guarantee availability or correctness of the surrounding interfaces and data feeds.

8. Responsible Disclosure and Ethical Hacking

Responsible disclosure is a structured process for reporting vulnerabilities so that affected parties have a fair opportunity to investigate and remediate them while reducing harm to users.

A mature disclosure policy should define:

• authorised reporting channels;
• systems and activities within scope;
• prohibited testing methods;
• safe-harbour conditions where legally available;
• expected acknowledgement and response times;
• treatment of good-faith research;
• coordination with affected suppliers and users;
• publication and credit practices;
• emergency escalation for active exploitation.

Ethical hackers must obtain explicit permission before testing. A public blockchain is observable, but that does not mean every form of interaction is authorised. Sending exploit transactions, probing a production endpoint, attempting to access personal information or extracting funds without permission can cause harm and may be unlawful.

A vulnerability report should include the affected component and version, reproduction steps, impact, evidence, suggested mitigation and the researcher’s contact details. Researchers should minimise data access, avoid persistence, stop when the issue is confirmed, preserve evidence and avoid public disclosure while remediation is reasonably possible. If a vulnerability is actively exploited, rapid coordination and user protection may take priority over ordinary timelines.

Organisations should not threaten good-faith researchers merely because a report is inconvenient. At the same time, a disclosure programme is not a licence for destructive testing, extortion, data theft or public release of an immediately exploitable method.

9. Surveillance, Power and Ethical Boundaries

Blockchain analytics can support fraud prevention and compliance, but extensive monitoring can create surveillance systems that affect privacy, autonomy and freedom of association. Ethical security practice asks not only whether monitoring is technically possible, but whether it is necessary, proportionate, accurate, transparent and subject to oversight.

Important safeguards include:

• a clearly defined legitimate purpose;
• collection of the minimum necessary data;
• access restrictions and audit trails;
• retention limits;
• quality checks and correction procedures;
• human review for consequential decisions;
• notice and appropriate challenge mechanisms;
• independent oversight;
• testing for discriminatory impact.

A risk score should not be treated as proof of misconduct. Blockchain attribution is uncertain, and an address may be shared, controlled by a custodian or falsely associated with a person. Automated blocking can deny access to legitimate users, particularly where individuals have limited ability to explain or challenge a decision.

Ethical governance also considers unequal power. A system may be lawful yet unfair if users cannot understand the rules, contest errors or choose an alternative. Decisions about identity, financial access and surveillance should be documented and reviewed by accountable people rather than hidden entirely inside algorithms.

10. Illustrative Case: The Meridian Digital Asset Platform

Background

Meridian is an illustrative fictional digital-asset platform that provides custody and settlement services to institutional clients. It operates a public-chain interface, uses a third-party cloud provider and relies on an external analytics vendor for AML alerts.

Problem

A single operations administrator could add a wallet address to the approved allowlist, change a daily transfer limit and approve a transfer. The same administrator also reviewed security logs. Meridian had commissioned a smart-contract audit, but the audited code differed from the version deployed after a later upgrade. The company stored customer identifiers in transaction metadata and had no formal vulnerability-disclosure policy.

Analysis

The central weaknesses were governance failures rather than one isolated coding error:

• incompatible privileges were concentrated in one role;
• audit scope did not cover the deployed version;
• customer data were unnecessarily exposed on-chain;
• monitoring lacked independent review;
• supplier responsibilities were not clearly documented;
• researchers had no safe channel for reporting vulnerabilities.

The risk was increased by the absence of effective evidence. Meridian could not readily prove who approved changes, whether alerts were investigated or whether recovery procedures had been tested.

Approach and solution

Meridian established a control committee and created a control register. It separated address administration, transfer approval, limit changes and log review. A 2-of-3 wallet was introduced for high-value transfers, with signers from different reporting lines and separate devices. Smart-contract releases were linked to a version-controlled build, independent review and a deployment approval record.

The company removed direct identifiers from new on-chain records and designed an off-chain identity mapping with restricted access. It revised supplier contracts to define incident notification, audit evidence, subcontractor disclosure and exit obligations. The AML programme added documented alert investigation, model-quality review and escalation to a compliance officer. Finally, Meridian published a vulnerability-disclosure policy and conducted an authorised tabletop exercise covering a stolen signing key and a smart-contract flaw.

Outcome

The measures did not eliminate risk, but they reduced single-person failure, improved evidence quality and made responsibilities visible. A later test identified a faulty transaction-limit configuration before production use because the new release process required independent review and simulation.

Learning points

1. A blockchain audit is meaningful only when its scope matches the deployed system.
2. Technical decentralisation does not prevent organisational concentration of power.
3. Privacy protection should be designed before data are written to an immutable ledger.
4. Compliance controls require documented investigation, not merely automated alerts.
5. Governance should make safe behaviour easier and unsafe behaviour harder.

11. Best-Practice Implementation Roadmap

An organisation beginning or improving a blockchain security programme can proceed in stages:

Stage 1: Establish accountability. Identify the board or executive sponsor, appoint control owners, define risk appetite and map legal obligations.

Stage 2: Map assets and dependencies. Inventory wallets, keys, contracts, nodes, applications, data, suppliers, privileged accounts and critical business processes.

Stage 3: Assess threats and obligations. Perform threat modelling, privacy-impact analysis, AML and sanctions risk assessment, and supplier-risk assessment.

Stage 4: Design controls. Implement least privilege, SoD, multisignature approvals, secure development, monitoring, reconciliation, incident response and recovery.

Stage 5: Generate evidence. Maintain approval records, logs, test results, training evidence, risk decisions, audit reports and remediation tracking.

Stage 6: Test and improve. Conduct independent reviews, penetration tests, recovery exercises, disclosure exercises and management reviews. Update controls after incidents, system changes or regulatory developments.

Challenges and Limitations

Governance controls have limitations. Excessive approval layers can delay legitimate transactions and encourage workarounds. Multisignature designs can fail if signers lose access or collude. Compliance analytics can produce false positives and false negatives. Audits are bounded by scope, time and available evidence. Privacy-preserving technologies may increase complexity, reduce interoperability or create new cryptographic and key-management risks. Legal requirements can differ across jurisdictions and may change rapidly.

Immutability is also contextual. A confirmed ledger record may be difficult to alter, but its interpretation, visibility, associated off-chain data and surrounding application can change. Organisations should avoid claiming that blockchain guarantees truth, privacy, compliance or permanence in every sense. Good governance recognises technical limits and maintains mechanisms for correction, redress and responsible intervention where law or safety requires it.

Chapter Summary

Blockchain security is a governance responsibility shared across technical, managerial, legal and ethical roles. Policies establish direction; controls translate direction into action; control owners are accountable for design and operation; audits and third-party assurance provide evidence but do not eliminate risk. Segregation of duties, least privilege and independent review reduce the impact of error and abuse, especially in wallet, deployment and treasury processes.

Privacy must be considered before data are placed on an immutable ledger. Off-chain storage, selective disclosure and data minimisation can reduce exposure, but hashes and transaction identifiers may still be linkable. AML, sanctions and cybersecurity compliance require risk-based processes, human judgement, documented evidence and continuous improvement. Responsible disclosure and authorised ethical hacking protect users when they are governed by clear scope and safe communication. Finally, surveillance and analytics must be necessary, proportionate, accurate and accountable. The strategic lesson is that trust in blockchain services depends not only on cryptography and consensus, but also on responsible institutions and verifiable decisions.

Key Terms

Anti-money laundering (AML): Measures designed to prevent and detect the concealment or movement of illicit funds.

Audit: A systematic evaluation of evidence against defined criteria.

Control: A measure that prevents, detects or corrects an unwanted event.

Control owner: The person accountable for a control’s design and operation.

Data minimisation: Collecting and retaining only data necessary for a legitimate purpose.

Design effectiveness: The extent to which a control would address its intended risk if performed correctly.

Ethical hacking: Authorised security testing performed to identify and reduce vulnerabilities.

Immutable ledger: A ledger designed to make confirmed records difficult to alter, subject to system assumptions and governance.

Least privilege: Providing only the access required for an authorised task.

Multisignature wallet: A wallet requiring signatures from multiple authorised keys.

Penetration test: An authorised, controlled attempt to identify exploitable weaknesses.

Privacy impact assessment: A structured analysis of how processing may affect individuals’ privacy.

Responsible disclosure: Coordinated reporting of vulnerabilities to enable remediation and reduce harm.

Risk acceptance: A documented decision to tolerate a specified residual risk.

Sanctions screening: Checking relevant persons, entities or transactions against applicable restrictions.

Segregation of duties: Dividing incompatible responsibilities among people or systems.

Third-party assurance: Independent evidence about controls operated by an external service provider.

Operating effectiveness: The extent to which a control operated consistently and as intended.

Review Questions

Short Answer Questions

1. What is the difference between a policy, a standard and a procedure?
2. Why is control ownership important in a blockchain organisation?
3. What problem does segregation of duties address?
4. Why does a public blockchain ledger not automatically provide AML compliance?
5. What is the purpose of a responsible-disclosure policy?

Long Answer Questions

1. Explain how governance operates at protocol, organisational, operational and ecosystem levels.
2. Compare internal audit, smart-contract audit, penetration testing and third-party assurance.
3. Discuss the privacy challenges created by immutable and transparent ledgers.
4. Describe a risk-based AML and sanctions compliance process for a digital-asset service.
5. Explain how least privilege, multisignature approval and independent review can protect a treasury wallet.

Analytical / Application Questions

1. A four-person team allows one developer to write, approve and deploy smart-contract upgrades. Identify the governance risks and design a revised control process.
2. A compliance model flags an address as high risk, but the customer disputes the result. Design a fair investigation and review process that addresses accuracy, privacy and due process.
3. A researcher discovers a vulnerability that could drain a production contract. Develop an immediate response plan covering authorisation, evidence preservation, disclosure, user protection and remediation.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a control owner?

A. The person who is accountable for the control’s design and operation

B. Any user who is affected by the control

C. The auditor who tests every control

D. The software vendor that supplies the blockchain

Correct Answer: A. The person who is accountable for the control’s design and operation

Question 2

What is the main purpose of segregation of duties?

A. To increase the number of blockchain transactions

B. To prevent one person from controlling incompatible sensitive activities

C. To make all decisions anonymous

D. To eliminate the need for audit evidence

Correct Answer: B. To prevent one person from controlling incompatible sensitive activities

Question 3

In a 2-of-3 multisignature wallet, how many distinct signatures are required for a transaction?

A. One

B. Two

C. Three

D. Four

Correct Answer: B. Two

Question 4

Why is a smart-contract audit not a guarantee that a system is secure?

A. Audits are always performed by software only

B. Audits have defined scope and may not cover later code changes or unknown flaws

C. Smart contracts cannot be tested

D. Audits examine only financial statements

Correct Answer: B. Audits have defined scope and may not cover later code changes or unknown flaws

Question 5

Which practice best supports blockchain privacy?

A. Publishing full customer identities in transaction metadata

B. Storing all personal records permanently on-chain

C. Using data minimisation and keeping sensitive information off-chain where appropriate

D. Assuming that every blockchain address is anonymous

Correct Answer: C. Using data minimisation and keeping sensitive information off-chain where appropriate

Question 6

Why does ledger transparency alone not establish AML compliance?

A. A ledger cannot record transfers

B. Transparency does not necessarily identify the person controlling an address or the purpose of a transfer

C. AML rules apply only to physical cash

D. Public ledgers automatically delete suspicious transactions

Correct Answer: B. Transparency does not necessarily identify the person controlling an address or the purpose of a transfer

Question 7

What must an ethical hacker have before testing a production blockchain service?

A. A public social-media account

B. Explicit authorisation and a defined scope

C. A personal mining rig

D. A promise that no report will be written

Correct Answer: B. Explicit authorisation and a defined scope

Question 8

Which is an appropriate safeguard when using blockchain analytics for compliance?

A. Treating every risk score as conclusive proof

B. Removing all human review

C. Using documented investigation and human review for consequential decisions

D. Publishing every customer’s analysis publicly

Correct Answer: C. Using documented investigation and human review for consequential decisions

Question 9

What is a major limitation of a third-party assurance report?

A. It may not cover the exact service, period or customer responsibilities relevant to the organisation

B. It can never contain evidence

C. It automatically replaces the organisation’s risk assessment

D. It applies only to personal wallets

Correct Answer: A. It may not cover the exact service, period or customer responsibilities relevant to the organisation

Question 10

Which action is most consistent with responsible disclosure?

A. Immediately publishing exploit code without contacting the affected party

B. Extracting funds to prove that the vulnerability is real

C. Reporting the issue through an authorised channel while minimising harm

D. Selling the vulnerability to unknown buyers

Correct Answer: C. Reporting the issue through an authorised channel while minimising harm