Cybersecurity, Privacy and Business Continuity

Introduction and Context

An accounting information system (AIS) is no longer confined to a server room and a finance department. It may include enterprise-resource-planning software, banking interfaces, payroll platforms, electronic invoicing, mobile devices, cloud applications, robotic process automation, data warehouses and artificial-intelligence tools. These connections improve speed and access, but they also expose accounting data and transaction processes to unauthorised access, manipulation, interruption and disclosure.

Cybersecurity in AIS concerns the protection of information and processing resources against threats to confidentiality, integrity and availability. Privacy concerns the lawful and ethical handling of information about identifiable individuals. Business continuity concerns the organisation’s ability to continue critical operations during and after disruption. These subjects are closely related but not identical. A system may be secure yet unavailable because of a flood; it may be available yet unreliable because transaction data were altered; or it may be operational but unlawful because personal information was used without a valid purpose.

For accountants, cybersecurity is not solely an information-technology responsibility. Accountants design controls, approve transactions, review exceptions, protect evidence, assess risks and communicate the financial consequences of incidents. The professional task is therefore to connect technical controls with assertions about financial information, legal obligations and organisational resilience.

Learning Objectives

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

1. Explain the confidentiality, integrity and availability objectives of AIS security.
2. Evaluate logical, physical and administrative access controls.
3. Distinguish authentication, authorisation, accounting and non-repudiation.
4. Explain the uses and limitations of encryption, network security and cloud controls.
5. Apply privacy principles to accounting data and assess privacy risks.
6. Describe incident response, evidence preservation and post-incident improvement.
7. Calculate and interpret recovery point objective, recovery time objective and availability measures.
8. Evaluate backup, disaster-recovery and business-continuity arrangements.
9. Recommend proportionate controls for an accounting environment.

1. The AIS Security Objective

A useful starting framework is the CIA triad:

• Confidentiality means that information is disclosed only to authorised persons or systems.
• Integrity means that information is accurate, complete, valid and protected from unauthorised or inappropriate alteration.
• Availability means that systems and information are accessible when required by authorised users.

Accounting controls add two important concerns. Authenticity asks whether a user, system or transaction is genuine. Accountability requires actions to be traceable to responsible individuals or processes. Audit trails, unique user identities and reliable timestamps support accountability.

Security objectives should be linked to business processes. For example, the integrity of supplier-bank details is critical because alteration can divert payments. The availability of a point-of-sale system may be critical during trading hours, while availability of an archival reporting system may be less urgent. A risk assessment should therefore consider the value of an asset, the likelihood of threats and the consequences of compromise.

A simple qualitative model is:

Risk = likelihood × impact

This is a prioritisation model rather than a precise scientific law. Likelihood and impact may be expressed as ordinal ratings, such as 1 to 5, provided the organisation defines the scales consistently. A high score indicates the need for stronger or more urgent treatment, but professional judgement remains necessary. Risks can be treated by reducing likelihood, reducing impact, transferring some consequences, avoiding the activity or accepting the residual risk with appropriate approval.

Common AIS threats

Threats include phishing, credential theft, ransomware, malicious insiders, accidental deletion, software vulnerabilities, fraudulent configuration changes, denial-of-service attacks, insecure application programming interfaces, cloud misconfiguration, equipment failure, fire, flood and power interruption. Threats become vulnerabilities when weaknesses permit them to cause harm. For example, phishing is a threat; password reuse and lack of multi-factor authentication are vulnerabilities; unauthorised payment is a potential impact.

2. Access Control and Segregation of Duties

Access control determines who or what may use a resource, what actions are permitted and under what conditions. Effective access control follows the principles of least privilege and need to know. A user should receive only the access necessary for assigned duties, for only as long as necessary.

Identification, authentication and authorisation

These concepts must be distinguished:

• Identification is the claimed identity, such as a username.
• Authentication verifies the claim, using a password, token, biometric characteristic or other evidence.
• Authorisation determines permitted actions after authentication.
• Accounting or logging records relevant activity for monitoring and investigation.

Multi-factor authentication (MFA) combines at least two different factor categories: something known, such as a password; something possessed, such as a security key; or something inherent, such as a fingerprint. Two passwords are not two independent factors. MFA substantially reduces the risk of stolen-password access, although phishing-resistant methods, such as hardware security keys, generally provide stronger protection than one-time codes entered into fraudulent websites.

Administrative and technical access controls

Administrative controls include security policies, onboarding and termination procedures, access reviews, training, disciplinary rules and approval requirements. Technical controls include role-based access control, network segmentation, privileged-access management, password managers, MFA, session timeouts and automated provisioning.

Role-based access control assigns permissions to job roles rather than directly to individuals. A maker-checker arrangement separates preparation from approval. For example, a clerk may create a supplier but a supervisor must approve the supplier before payments can be made. A segregation-of-duties (SoD) conflict exists when one person can perform incompatible activities, such as creating a supplier, entering an invoice and releasing payment.

Perfect segregation is not always practical in a small organisation. Compensating controls may include owner review of bank statements, independent payment approval, exception reporting and periodic access recertification. Compensating controls should be documented, performed by a suitably independent person and evidenced.

Access lifecycle

Access should be controlled throughout its lifecycle:

1. A manager requests access for a defined business purpose.
2. An owner approves the role and any privileged access.
3. The system provisions access using standard roles.
4. Activity is logged and unusual behaviour is monitored.
5. Access is reviewed periodically and after role changes.
6. Access is promptly revoked when employment or business need ends.

Dormant accounts, shared accounts and excessive administrator privileges are common weaknesses. Shared accounts make accountability difficult and should be avoided except where technically unavoidable and strongly controlled.

3. Encryption, Networks and Applications

Encryption transforms readable plaintext into ciphertext using an algorithm and a key. Decryption reverses the transformation for an authorised recipient. Encryption protects confidentiality, but it does not by itself guarantee that data are accurate, that the user is authorised or that the system is available.

Encryption in transit protects data moving across networks, normally through protocols such as Transport Layer Security (TLS). Encryption at rest protects stored data on disks, databases, backups and portable devices. Key management is crucial: keys should be protected, access should be restricted, rotation should be governed and recovery procedures should exist. If an organisation loses its decryption keys, encrypted backups may be unusable; if an attacker obtains the keys, encryption may offer little protection.

Integrity and authenticity are often supported by cryptographic hashes, message authentication codes and digital signatures. A hash produces a digest of data; a changed file normally produces a different digest. A hash alone does not prove who created the data. A digital signature uses a private key to sign and a corresponding public key to verify both origin and alteration, subject to sound key management and trust arrangements.

Network and endpoint risks

Network controls may include firewalls, secure configuration, intrusion detection, endpoint protection, vulnerability management, patching, secure remote access and segmentation. Segmentation limits the movement of an attacker. For example, a compromise of a marketing workstation should not automatically provide access to the general ledger database.

Wireless networks, virtual private networks, remote desktop services and application programming interfaces require explicit authentication, encryption and monitoring. Internet-facing services should be minimised and regularly tested. Vulnerability scanning identifies potential weaknesses, while penetration testing attempts to demonstrate exploitability within an agreed scope. Neither replaces secure design, patch management or business-process controls.

Endpoints should use supported operating systems, full-disk encryption, centrally managed security settings and controlled installation rights. Removable media and personal devices create risks of data loss and malware. Mobile-device management and clear bring-your-own-device rules are therefore relevant to accountants working remotely.

Application controls

AIS application controls include input validation, authorisation checks, sequence checks, duplicate detection, edit reports, automated calculations, interface reconciliations and exception handling. Cybersecurity should be integrated with the software-development lifecycle. Changes should be requested, tested, approved, migrated by authorised personnel and capable of being reversed. Emergency changes require retrospective review.

An accounting system may be technically secure but financially unreliable if interfaces fail silently. Daily reconciliations between subledgers, banks and the general ledger help identify missing, duplicated or altered transactions. Logs should capture user, time, action, old value, new value and relevant transaction identifier, subject to privacy and retention requirements.

4. Cloud Computing and Third-Party Risk

Cloud services can provide scalability, resilience and professional security capabilities, but moving an AIS to the cloud does not transfer all responsibility to the provider. In a shared-responsibility model, the provider may secure the underlying facilities and platform while the customer remains responsible for identities, configuration, data classification, user devices, interfaces and correct use.

Before selecting a cloud provider, an organisation should evaluate:

• service availability commitments and remedies;
• data location, transfer and deletion arrangements;
• encryption and key-management options;
• identity, logging and privileged-access controls;
• backup, restoration and disaster-recovery capabilities;
• independent assurance reports and penetration-test summaries;
• subcontractors and supply-chain dependencies;
• incident-notification procedures;
• exit, portability and business-continuity arrangements.

A service-level agreement is not a substitute for independent risk assessment. Contractual availability promises may exclude maintenance, customer misconfiguration or force majeure. Vendor concentration also matters: dependence on one provider or one integration may create systemic operational risk.

Cloud risks frequently arise from misconfiguration rather than an inherent defect in cloud technology. Publicly exposed storage, excessive permissions, unprotected API keys and disabled logging can disclose sensitive accounting and payroll information. Continuous configuration monitoring, strong identity controls and periodic supplier reviews are essential.

5. Privacy and the Responsible Use of Accounting Data

Accounting records often contain names, addresses, identification numbers, bank details, salaries, tax information and expense records. Privacy governance requires an organisation to determine what personal data it holds, why it holds them, who may access them, where they are processed and when they should be deleted or anonymised.

Although legal requirements vary by jurisdiction, widely recognised privacy principles include:

1. Lawfulness, fairness and transparency: processing should have a valid basis and be explained clearly.
2. Purpose limitation: data should be collected for specified legitimate purposes.
3. Data minimisation: collect and use only what is reasonably necessary.
4. Accuracy: maintain reliable information and correct errors.
5. Storage limitation: retain information only as long as justified by legal, operational or archival needs.
6. Security: protect data against unauthorised access, loss and disclosure.
7. Accountability: be able to demonstrate compliance.

Privacy is not achieved simply by deleting data immediately. Tax, company-law, audit and employment obligations may require retention. A retention schedule should reconcile these obligations with privacy principles, specify owners and define secure disposal.

A privacy impact assessment is useful when introducing high-risk processing, such as extensive employee monitoring, biometric authentication, automated profiling or a new cloud payroll service. The assessment should identify data subjects, purposes, data flows, risks, safeguards, residual risks and approval responsibilities.

Breach response and individual rights

A personal-data breach may involve unauthorised disclosure, loss, destruction or alteration. The response must establish facts quickly, contain the incident, assess affected data and comply with applicable notification duties. Depending on the law and circumstances, individuals, regulators, customers, employees, insurers and law enforcement may need to be informed.

Privacy also affects analytics and artificial intelligence. Training or prompting an AI system with confidential ledger, payroll or customer data may create unauthorised disclosure or retention risks. Organisations should define approved tools, prohibit sensitive uploads unless authorised, validate generated outputs and preserve human accountability for accounting judgements.

6. Incident Response and Digital Evidence

An incident-response capability converts an unexpected event into a managed process. A practical lifecycle is:

1. Preparation: establish policies, contacts, tools, training, backups and decision authority.
2. Detection and analysis: validate alerts, determine scope, classify severity and preserve evidence.
3. Containment: limit spread while avoiding unnecessary destruction of evidence.
4. Eradication: remove malicious access, correct vulnerabilities and reset compromised credentials.
5. Recovery: restore services safely, monitor for recurrence and reconcile transactions.
6. Lessons learned: identify root causes, control failures, financial effects and improvements.

The incident team should include information technology, finance, legal, privacy, communications, senior management, human resources and relevant suppliers. External specialists may be required for forensics, negotiation, regulatory notification or public communication.

Evidence must be handled carefully. Logs, emails, system images, access records, invoices and bank confirmations should be preserved with reliable timestamps and a documented chain of custody. Investigators should avoid altering original evidence and should record who collected, transferred, examined and stored it. Accountants should distinguish confirmed facts from assumptions and should consider whether transactions posted during compromise require reversal, re-performance or disclosure.

Ransomware illustrates the need for disciplined response. Paying a ransom does not guarantee recovery, may create legal or ethical issues and does not remove the attacker’s access or data copies. Restoration from tested backups, credential resets, vulnerability remediation and stakeholder communication are central controls.

7. Backup, Disaster Recovery and Business Continuity

These terms describe related but different capabilities:

• Backup is a copy of data or systems kept for restoration.
• Disaster recovery (DR) is the restoration of technology services and data after a disruptive event.
• Business continuity (BC) is the broader capability to continue critical products and processes at an acceptable level.
• Crisis management concerns strategic decisions, leadership and communications during a major event.

Business continuity begins with a business impact analysis (BIA). The BIA identifies critical processes, dependencies, maximum tolerable disruption and consequences over time. It should consider people, facilities, technology, suppliers, data, legal duties and manual workarounds.

Two important planning measures are:

• Recovery time objective (RTO): the targeted maximum time between service interruption and restoration of a service.
• Recovery point objective (RPO): the targeted maximum age of data that may be lost, measured backwards from the disruption.

If an AIS has an RPO of 30 minutes, the recovery design aims to lose no more than 30 minutes of transactions, assuming the objective is technically achieved. An RTO of four hours means the service should be restored within four hours; it does not necessarily mean every historical report is immediately available.

A simple availability measure is:

Here, uptime and downtime must be measured over the same defined period and must use a consistent definition of downtime. Planned maintenance may be included or excluded only according to a stated policy. For example, if a service operates for 8,760 hours in a year and is unavailable for 8 hours, availability is:

Availability = 8,752 ÷ 8,760 × 100% ≈ 99.91%

This percentage does not show whether the interruption occurred during a critical reporting deadline, so availability metrics should be supplemented by RTO compliance, incident severity and business impact.

Backup design

A resilient backup strategy normally includes multiple copies, different media or environments, geographic separation where appropriate, encryption, access restriction, retention rules and regular restoration tests. The widely used “3-2-1” principle recommends at least three copies, on at least two types of storage, with at least one copy stored separately from the primary environment. It is a useful baseline, not a universal guarantee.

Backups should be protected from ransomware through immutable or offline copies, separate credentials and restricted deletion rights. Backup success reports are not evidence that restoration will work. Tests should restore representative databases, applications, configurations and interfaces, then verify completeness and accounting integrity.

Recovery strategies

Strategies include manual procedures, reciprocal arrangements, cold sites, warm sites, hot sites, high-availability clusters and cloud-based recovery. A hot arrangement may reduce recovery time but usually costs more and can replicate corrupted data. A manual workaround may be adequate for low-volume processes but unsafe for high-volume payroll or payment operations. Recovery design should therefore follow the BIA rather than technology fashion.

After recovery, finance must reconcile transactions entered before, during and after the disruption. Duplicate postings, missing interfaces, incorrect exchange rates and unauthorised emergency entries are common risks. Management should approve controlled catch-up procedures and retain evidence of reconciliation.

8. Governance, Assurance and Control Evaluation

Cybersecurity and continuity require governance at board, management and operational levels. Policies should assign ownership for information assets, risk acceptance, incident escalation, privacy compliance, supplier oversight and continuity testing. Internal audit can evaluate design and operating effectiveness, while external assurance reports may provide evidence about service providers.

A control evaluation should ask:

1. What asset or process is being protected?
2. What threat and vulnerability are relevant?
3. What control is intended to prevent, detect or correct the event?
4. Who owns the control and how often does it operate?
5. What evidence demonstrates performance?
6. What is the residual risk?
7. Is there a compensating control if the primary control fails?

Useful indicators include privileged accounts without review, terminated users remaining active, unresolved critical vulnerabilities, failed backups, restoration-test success, phishing-reporting rates, unauthorised changes, incident response time and overdue access recertifications. Metrics should support decisions rather than reward superficial compliance. For example, a low incident count may indicate effective security—or poor detection and reporting.

Applied Case: Meridian Manufacturing’s Compromised Payment Process

Background

Meridian Manufacturing, an illustrative medium-sized company, used a cloud enterprise system for purchasing, accounts payable and general ledger processing. The finance manager approved suppliers and payments. Two clerks entered invoices, and the treasury officer uploaded payment files to the bank. MFA was enabled for the cloud system, but the bank portal used passwords and SMS codes. Supplier master-file changes were reviewed quarterly.

Problem

An accounts-payable clerk received a convincing phishing email and entered credentials into a fraudulent website. Attackers accessed the email account, observed a genuine supplier conversation and sent altered bank details for a large invoice. A clerk changed the supplier record, and the treasury officer released the payment. The fraud was discovered when the supplier reported non-payment two days later. During investigation, the company also found that one terminated employee’s cloud account remained active for three weeks.

Analysis

The incident involved failures in confidentiality, integrity and accountability. Email compromise exposed business information. The supplier record and payment instruction lost integrity. Delayed detection was enabled by weak change monitoring and the absence of independent confirmation using a trusted contact method. The SoD design was incomplete: the person changing supplier details was not the same person releasing payment, but there was no effective confirmation of the master-file change. The delayed account removal represented a lifecycle-control failure.

Approach and solution

Meridian immediately contacted the bank, suspended the supplier account and relevant credentials, preserved email and system logs, and notified its insurer and legal advisers. It reconciled recent supplier changes and payments. The company then introduced phishing-resistant MFA for privileged and banking access, dual approval for supplier-bank changes, independent call-back verification using existing records, automated alerts for changes to high-risk fields, daily review of payment exceptions and same-day termination processing.

It also revised its cloud contract, implemented immutable backups, tested restoration of the accounting system and established an incident-response team. Staff were trained to report suspicious messages without fear of blame. Internal audit performed a follow-up review after three months.

Outcome

The bank recovered part of the payment, and Meridian prevented two additional fraudulent changes identified through the new alerts. The incident caused financial loss, investigation costs and delayed supplier settlement, but the organisation improved both preventive and detective controls. Management accepted that MFA alone was not sufficient: identity security had to be combined with transaction verification and monitoring.

Learning points

1. Authentication of a user does not authenticate the truth of a transaction.
2. Supplier-master controls deserve the same attention as payment controls.
3. Independent verification should use a trusted channel, not the potentially compromised email thread.
4. Access termination is a time-sensitive control.
5. Incident response, backup and reconciliation are accounting responsibilities as well as technical activities.

Challenges, Limitations and Contemporary Developments

No control eliminates risk. Strong controls can reduce efficiency, create user frustration or encourage workarounds. Excessive monitoring may intrude on employee privacy. Biometric systems may create irreversible privacy consequences if biometric templates are compromised. Encryption can complicate lawful access, recovery and e-discovery. Cloud concentration may improve security while increasing dependency on a single provider.

Remote work, software supply-chain attacks, deepfake-enabled payment fraud, generative AI and increasingly automated finance processes are changing the threat environment. Deepfake voice or video should never replace established payment-authorisation procedures. AI-based anomaly detection can identify unusual amounts, locations or timing, but it may produce false positives, inherit biased data and be attacked through manipulated inputs. Human review, explainable escalation and audit trails remain necessary.

A mature AIS security programme is risk-based and continuously improved. It combines secure architecture, disciplined access management, privacy governance, resilient technology, trained personnel, tested recovery and independent assurance. The objective is not merely to prevent every incident—which is unrealistic—but to reduce likelihood, limit impact, detect quickly, recover reliably and learn systematically.

Chapter Summary

AIS cybersecurity protects confidentiality, integrity, availability, authenticity and accountability. Access control requires identification, strong authentication, least privilege, role-based permissions, segregation of duties and timely removal of access. Encryption protects data but depends on sound key management and does not replace authorisation or integrity controls. Network segmentation, secure endpoints, application controls, patching and monitoring reduce technical exposure.

Cloud services require attention to shared responsibility, configuration, contracts, suppliers, data location and exit arrangements. Privacy governance applies purpose limitation, minimisation, accuracy, retention, security and accountability to accounting and personal data. Incident response requires preparation, analysis, containment, eradication, recovery and lessons learned, supported by reliable evidence handling.

Business continuity begins with a business impact analysis. RTO defines the target restoration time, while RPO defines the acceptable age of recoverable data. Backups must be protected and restoration-tested. Disaster recovery restores technology; business continuity maintains critical operations. Effective governance connects these controls to financial reporting, legal duties, ethical responsibilities and management decisions.

Key Terms

Confidentiality: Protection against unauthorised disclosure of information.

Integrity: Accuracy, completeness and protection against unauthorised alteration.

Availability: Accessibility of systems and information when required.

Authentication: Verification of a claimed identity.

Authorisation: Determination of permitted actions or resources.

Multi-factor authentication: Authentication using two or more independent factor categories.

Least privilege: Granting only the access necessary for an approved purpose.

Segregation of duties: Dividing incompatible responsibilities among individuals or processes.

Encryption: Transformation of plaintext into ciphertext using an algorithm and key.

Hash: A fixed-length digest used to help detect data alteration.

Cloud shared responsibility: Allocation of security duties between a cloud provider and customer.

Privacy impact assessment: Structured evaluation of privacy risks and safeguards for proposed processing.

Incident response: Coordinated process for detecting, containing, resolving and learning from incidents.

Business impact analysis: Assessment of critical processes, dependencies and disruption consequences.

Recovery time objective: Target time for restoring a service after interruption.

Recovery point objective: Target maximum age of data that may be lost after disruption.

Backup: A copy of data or systems retained for restoration.

Disaster recovery: Restoration of technology services and data after disruption.

Business continuity: Capability to continue critical operations during and after disruption.

Residual risk: Risk remaining after controls and treatments are applied.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity and availability in an AIS.
2. Explain the difference between authentication and authorisation.
3. What is the purpose of segregation of duties in payment processing?
4. Define RTO and RPO.
5. Why should backups be tested through restoration rather than merely checked for completion?

Long Answer Questions

1. Explain how least privilege, role-based access and access recertification work together to protect an accounting system.
2. Discuss the security and governance issues an organisation should evaluate before adopting a cloud-based AIS.
3. Explain the main privacy principles and apply them to payroll and supplier data.
4. Describe the incident-response lifecycle and the role of accounting personnel at each stage.
5. Compare backup, disaster recovery and business continuity, including the role of a business impact analysis.

Analytical / Application Questions

1. A finance clerk can create suppliers, enter invoices and approve payments. Identify the SoD risks and design compensating controls for a small organisation where additional staff cannot be hired.
2. An AIS has an RTO of two hours and an RPO of 15 minutes. Evaluate whether a nightly backup alone can meet these objectives and recommend a more suitable recovery design.
3. A cloud payroll provider reports a security incident involving employee records. Develop an immediate response and governance plan covering containment, evidence, privacy assessment, communication and future controls.

Multiple Choice Questions with Answers

Question 1

Which security objective is primarily threatened when an unauthorised person changes a supplier’s bank account?

A. Confidentiality

B. Integrity

C. Availability

D. Portability

Correct Answer: B. Integrity

Question 2

Which combination represents two different authentication-factor categories?

A. Password and PIN

B. Username and password

C. Password and hardware security key

D. Two separate passwords

Correct Answer: C. Password and hardware security key

Question 3

What is the main purpose of segregation of duties?

A. To ensure every employee has administrator access

B. To divide incompatible responsibilities to reduce error and fraud risk

C. To eliminate the need for transaction logs

D. To increase the number of shared accounts

Correct Answer: B. To divide incompatible responsibilities to reduce error and fraud risk

Question 4

What does encryption at rest primarily protect?

A. Stored data

B. User job descriptions

C. Physical availability of a building

D. The accuracy of an accounting estimate

Correct Answer: A. Stored data

Question 5

Under a shared-responsibility cloud model, which responsibility normally remains with the customer?

A. Manufacturing the provider’s servers

B. Managing the provider’s building security guards

C. Configuring customer identities and permissions

D. Repairing the provider’s power grid

Correct Answer: C. Configuring customer identities and permissions

Question 6

Which privacy principle requires collecting only data reasonably necessary for a stated purpose?

A. Data minimisation

B. Availability

C. Non-repudiation

D. Reciprocity

Correct Answer: A. Data minimisation

Question 7

Which incident-response activity should normally occur before eradication?

A. Ignoring the alert

B. Containment

C. Deleting all logs

D. Closing the investigation

Correct Answer: B. Containment

Question 8

An organisation has 8,760 scheduled service hours and 8 hours of downtime. What is approximate availability?

A. 90.00%

B. 98.00%

C. 99.09%

D. 99.91%

Correct Answer: D. 99.91%

Question 9

An RPO of 30 minutes expresses which requirement?

A. The system must be restored within 30 minutes

B. No more than 30 minutes of data should be lost, subject to the design achieving the objective

C. Users may remain unauthorised for 30 minutes

D. Backups must be retained for 30 minutes only

Correct Answer: B. No more than 30 minutes of data should be lost, subject to the design achieving the objective

Question 10

Which action best demonstrates that a backup strategy is operationally reliable?

A. Confirming that a backup-success email was received

B. Increasing the number of user passwords

C. Performing and documenting a representative restoration test

D. Deleting the original accounting database

Correct Answer: C. Performing and documenting a representative restoration test