Governance, Controls, Security and Ethics

Introduction and Context

Enterprise resource planning (ERP) systems integrate finance, procurement, manufacturing, sales, human resources, supply-chain activities, and increasingly artificial intelligence into a shared information environment. This integration creates strategic value: managers obtain a common view of operations, transactions can be coordinated across organizational boundaries, and data can support faster decisions. It also creates concentrated risk. A single inaccurate master-data record, excessive user privilege, compromised integration, or unethical algorithm can affect several functions simultaneously.

ERP governance therefore cannot be treated as an information-technology concern alone. It is an enterprise system of accountability through which the organization directs, controls, monitors, and improves the use of ERP resources and information. Governance connects business strategy, risk appetite, internal control, cybersecurity, privacy, regulatory obligations, and ethical principles. At graduate level, the central question is not simply whether an ERP system is secure, but whether its design and operation produce trustworthy organizational outcomes.

This chapter examines governance structures, segregation of duties, identity and access management, auditability, cybersecurity, privacy, regulatory compliance, responsible data practices, and algorithmic risk. It also considers the tensions among efficiency, control, transparency, employee autonomy, and innovation.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain ERP governance and distinguish it from routine system administration.
2. Design a control framework incorporating accountability, segregation of duties, access control, change management, and monitoring.
3. Evaluate ERP cybersecurity and privacy risks across applications, infrastructure, integrations, people, and processes.
4. Interpret the role of audit trails, evidence, compliance, and continuous control monitoring.
5. Analyze ethical issues involving data collection, surveillance, automation, bias, explainability, and algorithmic decision-making.
6. Recommend governance improvements for a complex ERP implementation while balancing operational performance and control effectiveness.

1. ERP Governance as an Enterprise Capability

Governance is the allocation of decision rights and accountability for achieving organizational objectives. Management operates the business within those arrangements; governance determines who is authorized to decide, what evidence is required, how risk is accepted, and how performance is reviewed.

A useful governance model contains five mutually dependent elements:

• Strategic alignment: ERP priorities reflect business strategy, operating-model choices, and regulatory obligations.
• Decision rights: A steering committee, process owners, data owners, security officers, and technology leaders have explicit authority.
• Risk oversight: Threats to confidentiality, integrity, availability, privacy, compliance, and ethical legitimacy are assessed.
• Performance and assurance: Controls, service levels, audit findings, incidents, and benefits are measured.
• Continuous improvement: Lessons from incidents, changing regulations, new technologies, and user experience feed back into design.

ERP governance is broader than an ERP project steering committee. A project committee may authorize scope, budget, and milestones; ongoing governance must also control role design, master data, releases, integrations, vendors, retention, and model behavior after go-live.

Governance roles

The board or senior executive committee establishes risk appetite and accountability. An ERP steering committee resolves cross-functional priorities. Process owners are accountable for end-to-end processes such as procure-to-pay or order-to-cash. Data owners define data quality, access, classification, retention, and permissible use. The chief information security officer coordinates security risk, while internal audit provides independent assurance rather than operating controls. System administrators and application teams implement controls but should not unilaterally approve their own access or changes.

A responsibility assignment matrix, often expressed as RACI—responsible, accountable, consulted, and informed—can expose gaps. For example, a procurement director may be accountable for supplier-master governance, an ERP analyst responsible for workflow configuration, legal counsel consulted on privacy, and internal audit informed through assurance reporting. RACI does not replace control ownership; it clarifies it.

2. Internal Control Architecture

Internal controls are policies, procedures, configurations, and behaviors designed to provide reasonable—not absolute—assurance that objectives will be achieved. In ERP environments, controls should be considered at three levels:

1. Entity-level controls, such as ethics policies, oversight, risk assessment, and competence.
2. Process-level controls, such as approval of purchase orders, three-way matching, payroll review, and inventory reconciliation.
3. Technology-level controls, such as authentication, logging, backup, vulnerability management, interface validation, and change control.

The classic control objectives are confidentiality, integrity, availability, authenticity, accountability, and compliance. Integrity is especially important in ERP because incorrect transactions may propagate across ledgers, inventory balances, tax calculations, and management reports.

Controls may be preventive, detective, or corrective. A workflow that prevents a buyer from approving their own purchase is preventive. A report identifying duplicate suppliers is detective. Restoring a verified backup after data corruption is corrective. Controls may also be manual, automated, or hybrid. Automation improves consistency and scale, but configuration errors can systematically reproduce an incorrect result; therefore automated controls require design review, testing, and monitoring.

A control should have a stated objective, owner, frequency, population or trigger, evidence, exception process, and review criteria. “The system is secure” is not a testable control statement. “Each privileged-access request is approved by the system owner and security function before activation, and quarterly recertification evidence is retained” is more auditable.

3. Segregation of Duties and Conflict Management

Segregation of duties (SoD) reduces the possibility that one person can initiate, authorize, execute, record, and conceal an improper transaction. Typical incompatible combinations include:

SoD is not merely a list of job titles. It is an analysis of permissions, process steps, organizational context, and compensating controls. In a small subsidiary, complete separation may be impractical. Risk can be reduced through independent review, transaction thresholds, exception reports, dual approval, privileged-session recording, or periodic reconciliation. These measures reduce but do not eliminate residual risk.

A mature SoD program maintains a conflict matrix, maps business roles to technical permissions, evaluates actual user assignments, documents approved exceptions, and reviews conflicts after organizational or system changes. Emergency access should be time-limited, justified, logged, and reviewed after use. Generic accounts are particularly problematic because they weaken individual accountability; if technically unavoidable, they require compensating authentication and monitoring.

4. Identity and Access Management

Access should follow the principles of least privilege, need to know, default deny, and timely revocation. Least privilege means users receive only the permissions necessary for authorized tasks. Need to know restricts access to information required for a legitimate purpose, even when a user has a broad functional role. Default deny means access is not granted unless explicitly authorized.

A sound identity and access management lifecycle includes:

1. Joiner: verified identity, approved role, appropriate training, and time-bounded access where possible.
2. Mover: reassessment when duties, location, manager, or employment status changes.
3. Leaver: prompt deactivation, token revocation, recovery of devices, and reassignment of ownership.
4. Periodic review: managers and data owners recertify access based on actual responsibilities.
5. Privileged access: stronger authentication, separate administrative identities, session logging, and heightened review.

Role-based access control (RBAC) assigns permissions to roles rather than directly to individuals. Attribute-based access control (ABAC) additionally evaluates attributes such as department, location, device posture, time, transaction value, and data classification. RBAC is administratively simpler; ABAC can express more contextual policies but is harder to design, test, and explain.

Multi-factor authentication should protect remote, privileged, and high-risk access. Authentication verifies identity; authorization determines permitted action; accounting or audit logging records what occurred. These functions must not be conflated. A successfully authenticated user may still be unauthorized to export payroll data.

Access recertification should be evidence-based rather than a routine “approve all” exercise. Reviewers need understandable reports showing the user, role, sensitive permissions, conflicts, last use, and business justification. Unused access is not automatically harmless: dormant privilege can become valuable during account compromise.

5. Audit Trails, Evidence, and Continuous Monitoring

An audit trail is a chronological record of relevant events, such as authentication, authorization changes, master-data changes, transaction creation, approval, reversal, interface exchange, configuration change, and privileged activity. It supports accountability, forensic investigation, operational troubleshooting, financial assurance, and regulatory response.

Effective logs should answer who acted, what happened, when it happened, where or from which system it occurred, what was changed, and whether the action succeeded. Time synchronization is essential for correlating events across ERP modules, identity platforms, cloud services, and security tools. Logs should be protected against unauthorized alteration, retained according to legal and business requirements, and made available to authorized investigators.

Logging everything is not the same as auditability. Excessive unstructured data can obscure significant events and increase privacy exposure. Organizations should define logging requirements according to risk and legal necessity. Examples of high-value monitoring include changes to supplier bank accounts, unusual payment behavior, mass exports, privileged-role assignments, repeated authentication failures, and changes to tax or posting configuration.

Continuous control monitoring uses automated tests to identify exceptions close to the time of occurrence. It can detect duplicate invoices, transactions outside approval thresholds, incompatible role combinations, inactive users with access, or interfaces that fail validation. Monitoring should have a defined owner and response process; an alert without investigation capacity becomes operational noise.

Internal audit evaluates governance and control effectiveness independently. External assurance may assess financial reporting, service providers, cybersecurity, or privacy controls. Evidence should demonstrate not merely that a policy exists, but that the control operated consistently and that exceptions were resolved.

6. Cybersecurity in ERP Environments

ERP cybersecurity is a socio-technical problem. Threats arise from external attackers, malicious insiders, careless users, compromised vendors, vulnerable applications, misconfigured cloud services, and weak integrations. Common attack paths include credential theft, phishing, ransomware, exploitation of unpatched components, insecure application programming interfaces, supply-chain compromise, and manipulation of master data.

A defense-in-depth architecture may include network segmentation, secure configuration, endpoint protection, identity controls, encryption in transit and at rest, vulnerability management, application security testing, backup isolation, security information and event management, incident response, and employee awareness. No single control is sufficient. Encryption, for example, does not prevent an authorized but unethical user from exporting decrypted data.

The confidentiality, integrity, and availability triad remains useful, but ERP operations require additional attention to authenticity, non-repudiation, resilience, and recoverability. Recovery objectives should be explicit:

• Recovery time objective (RTO): maximum acceptable time to restore a service after disruption.
• Recovery point objective (RPO): maximum acceptable period of data loss measured backward from the disruption.

For example, an RPO of 15 minutes means that, under the recovery design, the organization aims to lose no more than approximately 15 minutes of transactional data. RTO and RPO are management requirements, not guarantees; they must be tested through realistic exercises.

Incident response normally includes preparation, detection and analysis, containment, eradication, recovery, and lessons learned. Legal, privacy, communications, human resources, and business continuity teams should be included where an incident involves personal data or material operational impact. Evidence preservation must be balanced with the need to restore operations.

Third-party and cloud risks deserve special attention. Contracts should define security responsibilities, breach notification, audit rights, data location, subcontractors, service continuity, return or deletion of data, and access to evidence. The shared-responsibility model does not transfer all accountability to the cloud provider; the customer remains responsible for many configurations, identities, data uses, and business decisions.

7. Privacy and Responsible Data Practices

Privacy is not identical to security. Security protects information from unauthorized access or misuse; privacy concerns whether information is collected, used, disclosed, retained, and deleted in legitimate, fair, and proportionate ways. An organization can have strong cybersecurity and still violate privacy by collecting excessive employee data or using it for an undisclosed purpose.

Responsible ERP data practices include:

• Purpose limitation: collect and use data for specified legitimate purposes.
• Data minimization: collect only what is reasonably necessary.
• Accuracy: provide mechanisms to correct materially inaccurate records.
• Storage limitation: retain data no longer than justified by law, operations, or evidence requirements.
• Transparency: explain relevant processing in understandable language.
• Access and accountability: restrict use and demonstrate compliance.
• Privacy by design: incorporate privacy into process and system design rather than adding it after deployment.

Privacy impact assessments are useful when introducing employee monitoring, biometric authentication, location tracking, large-scale analytics, or AI-supported decisions. The assessment should identify data subjects, purposes, data flows, risks, safeguards, residual risk, and consultation requirements.

Data classification helps determine handling requirements. Public, internal, confidential, and highly restricted categories may require progressively stronger access, encryption, retention, and monitoring. Masking or tokenization can reduce exposure in development and testing. Anonymization may reduce identifiability, but it must be assessed carefully because combining datasets can enable re-identification.

Regulatory obligations vary by jurisdiction and sector. Examples include data-protection laws, financial reporting requirements, tax rules, labor law, records-management duties, anti-bribery provisions, export controls, and industry-specific requirements. Compliance should be mapped to concrete ERP controls, evidence, owners, and review frequencies. Legal compliance is a baseline, not a complete ethical standard.

8. Ethics, Algorithms, and Automated Decisions

ERP systems increasingly embed analytics and AI in credit approval, supplier scoring, fraud detection, workforce scheduling, demand forecasting, performance assessment, and inventory decisions. Automation can improve consistency and speed, but it can also obscure responsibility and amplify historical discrimination.

Important ethical principles include:

• Fairness: similarly situated people should not receive unjustifiably different treatment.
• Explainability: affected users should receive an intelligible account of relevant factors and decision logic.
• Contestability: individuals should have a meaningful route to challenge an outcome.
• Human accountability: responsibility cannot be delegated to an algorithm merely because software produced the recommendation.
• Proportionality: the intrusiveness and consequences of processing should be proportionate to the legitimate objective.
• Safety and robustness: models should perform acceptably under expected changes and adversarial conditions.

Fairness is context-dependent. A model may have similar error rates across groups but still produce unequal access to opportunities if the underlying labels reflect past discrimination. Conversely, enforcing one statistical parity measure may reduce accuracy or conflict with another legitimate objective. Managers should therefore avoid treating a single fairness metric as a universal ethical answer.

Model governance should include an inventory of models, documented purpose and owner, data provenance, performance measures, subgroup testing, validation independent of development, version control, drift monitoring, approval thresholds, human review, incident procedures, and retirement criteria. High-impact decisions require stronger oversight than low-risk recommendations.

Generative AI creates additional risks: confidential ERP data may be disclosed to an external service; generated explanations may be inaccurate; and automated outputs may create fabricated records or unauthorized commitments. Organizations should define approved tools, prohibit entry of restricted data into unapproved services, validate outputs, and preserve human responsibility for decisions and postings.

9. Compliance and Control Frameworks

Organizations commonly align ERP controls with several overlapping frameworks. The COSO internal control framework emphasizes control environment, risk assessment, control activities, information and communication, and monitoring. COBIT provides governance and management guidance for enterprise information and technology. ISO/IEC 27001 supports an information-security management system based on risk treatment and continual improvement. NIST guidance provides widely used cybersecurity functions and practices. Privacy frameworks and sector regulations add requirements concerning lawful processing, individual rights, retention, and breach response.

These frameworks are not checklists to be copied without interpretation. A control library should map each obligation to:

1. the risk or requirement;
2. the control objective;
3. the control activity and system configuration;
4. the owner and frequency;
5. the evidence produced;
6. the testing method;
7. the exception and remediation process.

A mature compliance program seeks rationalization. If five policies require substantially the same access review, one well-designed control may satisfy several obligations, provided its scope and evidence are sufficient. Conversely, a control designed for financial reporting may not address privacy or cyber resilience.

10. Implementation and Change Governance

Governance is most effective when designed before configuration becomes difficult to change. During ERP implementation, organizations should establish a control baseline, classify data, define role principles, document critical processes, identify regulatory requirements, and approve design decisions through traceable forums.

Change management should distinguish normal, standard, emergency, and major changes. A controlled change generally requires a documented request, impact and risk assessment, testing, approval, deployment authorization, rollback plan, and post-implementation review. Segregation between development, testing, and production reduces the risk of unreviewed code or configuration reaching live operations.

Configuration and customization choices have governance consequences. Excessive customization can increase vulnerabilities, upgrade difficulty, and dependence on individuals. Excessive standardization can force unsafe workarounds or ignore legitimate legal and operational needs. The proper decision evaluates process value, control impact, maintainability, total cost, and reversibility.

Training should address not only system操作 but also ethical and control responsibilities: protecting credentials, recognizing phishing, handling personal data, reporting conflicts, and challenging suspicious instructions. A strong culture makes it safe to report control failures and inappropriate data use.

Illustrative Case: Northstar Components’ ERP Transformation

Background

Northstar Components, a fictional multinational manufacturer, implemented a cloud ERP system across three countries. The project integrated procurement, inventory, production, sales, finance, and payroll. Senior leaders expected faster closing, lower inventory, and improved supplier visibility.

Problem

Six months after go-live, internal audit identified three issues. Several purchasing managers could create suppliers and approve purchase orders. A temporary implementation consultant retained privileged access after contract completion. Finally, a machine-learning supplier-risk score used historical late-payment data that disproportionately penalized small suppliers from one region. The system generated extensive logs, but no team owned daily review of high-risk events.

Analysis

The problems were connected. Governance had treated security as a technical workstream rather than an end-to-end accountability issue. Role design had been copied from legacy job titles without analyzing incompatible activities. The access lifecycle lacked an automated termination trigger. The algorithm had been validated for predictive accuracy but not for disparate impact or contestability. Logging existed, but monitoring and response ownership did not.

Approach and Solution

Northstar established an ERP risk committee chaired by the chief operating officer and including finance, procurement, HR, legal, privacy, security, internal audit, and data-governance representatives. It appointed process and data owners and approved a RACI matrix.

The organization mapped critical procure-to-pay activities and removed direct conflicts. Supplier creation was separated from purchase approval and payment release. Exceptions were permitted only with documented business justification, independent review, and monthly reporting. Privileged accounts were separated from ordinary user accounts, protected with multi-factor authentication, and automatically disabled at contract end.

A control-monitoring service generated alerts for supplier-bank changes, mass exports, unusual payment patterns, and incompatible access. The security team owned triage, while process owners investigated business exceptions. Logs were time-synchronized and retained according to documented requirements.

The supplier-risk model was placed in a model inventory. Northstar reviewed feature relevance, removed a proxy variable with weak business justification, tested performance across supplier groups, published an understandable explanation, and introduced a human review and appeal process. Procurement staff were instructed that the score was decision support, not an automatic exclusion rule.

Outcome

In this illustrative case, Northstar reduced standing privileged access, improved evidence for control testing, and identified several erroneous supplier records before payment. The model became more transparent, although its predictive performance declined slightly. Management accepted the trade-off because the new process better supported fairness, contestability, and supplier trust.

Learning Points

The case demonstrates that governance is an operating capability, not a document. SoD, access management, auditability, privacy, and algorithmic ethics must be integrated. It also shows that control improvements can create costs or reduce narrow technical performance; responsible management evaluates broader organizational value rather than optimizing a single metric.

Challenges and Limitations

First, controls can become excessive. Approval layers may slow legitimate operations, encourage workarounds, and obscure accountability. Risk-based design is preferable to identical controls for every transaction.

Second, segregation can conflict with scarce expertise and small-team realities. Compensating controls must be genuinely independent and capable of detecting abuse; a superficial review by a close colleague is weak assurance.

Third, compliance frameworks may generate documentation without improving outcomes. Evidence should be connected to decisions, incidents, and measurable risk reduction.

Fourth, privacy and security requirements can conflict with analytics ambitions. Data minimization may reduce model inputs, while broad data access increases exposure. The appropriate response is purpose-specific architecture, controlled access, privacy-preserving techniques, and explicit acceptance of residual risk.

Fifth, algorithmic fairness cannot be resolved solely through technical adjustment. It involves organizational purpose, power, historical inequality, legal interpretation, and affected stakeholders. Quantitative testing is necessary in many cases but not sufficient.

Finally, cloud services, APIs, robotic process automation, and AI expand the control boundary. Traditional ERP governance must therefore include vendors, data exchanges, models, devices, and human-machine interactions.

Best-Practice Design Principles

1. Establish business ownership for every critical process and data domain.
2. Translate risks into testable control objectives with named owners.
3. Design roles around activities and conflicts, not legacy titles.
4. Apply least privilege, multi-factor authentication, timely deprovisioning, and privileged-access monitoring.
5. Protect and review high-value audit trails, rather than merely collecting logs.
6. Test backups, recovery objectives, incident response, and third-party continuity.
7. Embed privacy, retention, and ethical review in process design.
8. Maintain model inventories and require validation, explainability, monitoring, and appeal for high-impact uses.
9. Use independent assurance and preserve evidence of exceptions and remediation.
10. Reassess controls after acquisitions, reorganizations, new integrations, regulatory change, and major system releases.

Chapter Summary

ERP governance establishes decision rights, accountability, risk oversight, assurance, and continuous improvement for integrated enterprise information. Effective control architecture combines entity-level governance, process controls, and technology controls. Segregation of duties reduces opportunities for fraud and error, while role-based or attribute-based access, multi-factor authentication, and lifecycle management limit unauthorized activity.

Audit trails support accountability and investigation only when events are meaningful, protected, time-synchronized, retained appropriately, and actively reviewed. Cybersecurity requires defense in depth, resilience, tested recovery objectives, incident response, and careful management of cloud and third-party responsibilities. Privacy requires more than confidentiality: organizations must justify collection, limit use, maintain accuracy, control retention, and explain processing.

Ethical ERP management treats fairness, explainability, contestability, proportionality, and human accountability as governance requirements. AI models require documented purposes, data provenance, subgroup evaluation, independent validation, monitoring, and appropriate human oversight. Finally, frameworks such as COSO, COBIT, ISO/IEC 27001, and NIST are most useful when translated into owned, testable, evidence-based controls. The strategic objective is trustworthy digital operations—not compliance theater or maximum restriction.

Key Terms

ERP governance: The structures and processes used to direct, control, and oversee ERP resources and decisions.

Segregation of duties: Division of incompatible responsibilities to reduce error, fraud, and concealment risk.

Least privilege: Provision of only the access necessary for an authorized task.

Need to know: Restriction of information access to data required for a legitimate purpose.

Role-based access control: Access assignment through organizational or functional roles.

Attribute-based access control: Access decisions using contextual attributes and policy rules.

Privileged access: Elevated permission capable of changing systems, configurations, or sensitive data.

Audit trail: Chronological evidence of system and user events.

Continuous control monitoring: Automated or frequent testing that identifies control exceptions.

Preventive control: A control intended to stop an unwanted event before it occurs.

Detective control: A control intended to identify an event or condition after or during occurrence.

Recovery time objective: The maximum acceptable time to restore a service after disruption.

Recovery point objective: The maximum acceptable period of data loss measured backward from disruption.

Privacy by design: Incorporating privacy safeguards into systems and processes from the outset.

Data minimization: Limiting collection and use to what is necessary for a stated purpose.

Model governance: Oversight of an algorithm’s purpose, data, validation, deployment, monitoring, and retirement.

Explainability: The ability to provide an understandable account of how or why an outcome was produced.

Contestability: The opportunity for an affected person to challenge or appeal a decision.

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

Review Questions

Short Answer Questions

1. What is the difference between ERP governance and ERP system administration?
2. Why is segregation of duties important in a procure-to-pay process?
3. Distinguish authentication, authorization, and accounting.
4. What do RTO and RPO measure?
5. Why is privacy broader than information security?

Long Answer Questions

1. Explain how entity-level, process-level, and technology-level controls work together in an ERP environment.
2. Compare RBAC and ABAC, including the advantages and implementation challenges of each.
3. Discuss the characteristics of an effective ERP audit-trail and continuous-monitoring program.
4. Explain how an organization should govern AI-supported decisions in procurement or human resources.
5. Evaluate the roles of COSO, COBIT, ISO/IEC 27001, and NIST in an integrated ERP control program.

Analytical / Application Questions

1. A finance employee can create suppliers, modify supplier bank accounts, enter invoices, and release payments. Analyze the risks, propose a revised role design, and identify compensating controls for unavoidable exceptions.
2. An ERP implementation team wants to send employee performance data to a generative-AI service for automated recommendations. Design a governance assessment covering privacy, security, ethics, vendor risk, human oversight, and data retention.
3. A supplier-risk model produces fewer late-payment losses but rejects substantially more small regional suppliers. Develop an investigation and remediation plan that balances predictive performance, fairness, explainability, business objectives, and supplier appeal rights.

Multiple Choice Questions with Answers

Question 1

Which statement best describes ERP governance?

A. Routine correction of user passwords and printer settings

B. Allocation of decision rights and accountability for directing and controlling ERP resources

C. Replacement of all manual business processes with automation

D. A technical procedure for installing database patches

Correct Answer: B. Allocation of decision rights and accountability for directing and controlling ERP resources

Question 2

Which combination presents the clearest segregation-of-duties conflict?

A. Viewing a purchase order and receiving an email notification

B. Creating a supplier and independently reviewing supplier performance

C. Creating a supplier and releasing payment to that supplier

D. Preparing a report and presenting it to a process owner

Correct Answer: C. Creating a supplier and releasing payment to that supplier

Question 3

What does least privilege require?

A. Every employee receives administrator access during implementation

B. Users receive only the permissions necessary for authorized tasks

C. Access is granted permanently to avoid workflow delays

D. Managers can access all data held by their departments

Correct Answer: B. Users receive only the permissions necessary for authorized tasks

Question 4

Which control is primarily detective?

A. A workflow preventing a buyer from approving their own purchase

B. Multi-factor authentication at login

C. A report identifying duplicate invoices after entry

D. A rule blocking an invoice above an approval threshold

Correct Answer: C. A report identifying duplicate invoices after entry

Question 5

An RPO of 15 minutes primarily describes:

A. The maximum target time to restore service

B. The maximum target period of transactional data that may be lost

C. The maximum time a user may remain logged in

D. The maximum time allowed for an audit interview

Correct Answer: B. The maximum target period of transactional data that may be lost

Question 6

Which statement correctly distinguishes privacy from security?

A. Privacy concerns only encryption, while security concerns only retention

B. Privacy concerns legitimate and proportionate data use; security protects data from unauthorized access and misuse

C. Privacy is relevant only to consumer data, not employee data

D. Security compliance automatically proves ethical data use

Correct Answer: B. Privacy concerns legitimate and proportionate data use; security protects data from unauthorized access and misuse

Question 7

Which practice most directly supports privileged-access accountability?

A. Using a shared administrator account for convenience

B. Disabling all system logs to reduce storage costs

C. Using separate administrative identities with strong authentication and session monitoring

D. Allowing contractors to retain access after their contracts end

Correct Answer: C. Using separate administrative identities with strong authentication and session monitoring

Question 8

Why is an audit trail insufficient by itself?

A. Audit trails cannot record successful transactions

B. Collected logs require protection, appropriate retention, review ownership, and response processes

C. Audit trails are useful only for debugging software code

D. Audit trails eliminate the need for access controls

Correct Answer: B. Collected logs require protection, appropriate retention, review ownership, and response processes

Question 9

Which principle gives an affected person a meaningful opportunity to challenge an automated decision?

A. Contestability

B. Data minimization

C. Availability

D. Network segmentation

Correct Answer: A. Contestability

Question 10

Which is an appropriate governance practice for a high-impact AI model embedded in an ERP process?

A. Deploying it without documenting its purpose to preserve flexibility

B. Evaluating only overall accuracy and ignoring subgroup performance

C. Maintaining model ownership, validation, monitoring, explanations, and human review

D. Treating the model output as automatically correct because it is statistical

Correct Answer: C. Maintaining model ownership, validation, monitoring, explanations, and human review