Security, Privacy, Ethics and Governance

Introduction and Context

Distributed computing has transformed the security problem from protecting a bounded system to governing interactions among users, services, devices, platforms, networks, and jurisdictions. A transaction may cross several cloud regions, invoke third-party APIs, use open-source components, and process personal data under multiple legal regimes. Consequently, security cannot be treated as a perimeter appliance or as a final testing phase. It must be designed as a continuous system property supported by identity, cryptography, policy, monitoring, governance, and accountability.

The central challenge is to make distributed systems dependable despite physical separation, partial failure, dynamic membership, heterogeneous administration, and imperfect trust. Confidentiality, integrity, availability, authenticity, privacy, safety, and accountability must be considered together. A technically secure design may still be unacceptable if it violates data-sovereignty requirements, enables unjustified surveillance, produces discriminatory decisions, or cannot explain who accessed data and why.

This chapter examines distributed identity, authentication and authorization; zero-trust networking; encryption and key management; software supply-chain security; privacy and data sovereignty; auditability and responsible monitoring; regulatory compliance; and ethical governance. The emphasis is on design reasoning rather than on any single product or vendor.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain why identity is the primary security boundary in distributed systems.

2. Distinguish authentication, authorization, accountability, and non-repudiation.

3. Design a zero-trust access model using policy, context, and continuous verification.

4. Select suitable encryption and key-management strategies for distributed data.

5. Analyze software supply-chain risks and propose controls.

6. Evaluate privacy, sovereignty, auditability, and responsible-monitoring requirements.

7. Relate technical controls to governance, regulation, ethics, and organizational risk.

8. Critically assess security architectures through an applied case.

1. Security Properties in Distributed Systems

A distributed system contains multiple principals: human users, workloads, administrators, services, devices, and external organizations. These principals communicate through networks that may be hostile or merely unreliable. The traditional security objectives are:

• Confidentiality: information is disclosed only to authorized parties.
• Integrity: information and computation are not altered improperly.
• Availability: authorized users can obtain services when needed.
• Authenticity: an identity, message, or service is genuine.
• Accountability: actions can be attributed to responsible principals.
• Privacy: individuals retain appropriate control over information about them.

These objectives can conflict. Strong inspection may improve fraud detection but reduce privacy. Aggressive availability controls may increase denial-of-service exposure. Broad administrative access may simplify operations while weakening least privilege. Security engineering is therefore a risk-management activity: controls should be proportionate to assets, threats, legal duties, and consequences.

Distributed systems introduce distinctive threats. Credentials can be replayed across services; inconsistent policy replicas can authorize conflicting actions; compromised service accounts can move laterally; clock differences can complicate event ordering; and a third-party dependency can compromise many organizations simultaneously. Security architecture must account for both malicious behavior and accidental misconfiguration.

2. Distributed Identity and Access Management

2.1 Identity as a control plane

Identity management answers four related questions:

1. Who or what is requesting access?

2. How was that identity verified?

3. What is the requester allowed to do?

4. What evidence records the decision and subsequent action?

An identity is a managed representation of a principal, not merely a username. It may include attributes such as organization, role, device status, workload identity, assurance level, and lifecycle state. Identity systems commonly include an identity provider (IdP), relying parties, credential stores, policy decision points, and audit services.

Federation permits one domain to accept identity assertions issued by another. Standards such as SAML and OpenID Connect support federated authentication, while OAuth 2.0 primarily provides delegated authorization. These mechanisms should not be confused: authentication establishes identity; authorization determines permitted action; delegation allows a client to act with scoped authority.

2.2 Authentication

Authentication mechanisms include knowledge factors, possession factors, inherence factors, and cryptographic credentials. Password-only authentication is vulnerable to phishing, reuse, guessing, and credential stuffing. Multi-factor authentication improves assurance when factors are independent. Phishing-resistant methods, including hardware-backed credentials and public-key authenticators, are generally stronger than one-time codes that can be relayed.

For machine-to-machine communication, long-lived shared secrets are operationally dangerous. Better approaches include short-lived certificates, workload identities, hardware-backed keys, and token exchange. A workload identity should be bound to the service, environment, and intended audience, rather than copied as a static secret into configuration files.

Authentication strength is contextual. A low-risk read operation may require a different assurance level from a financial transfer or production deployment. Adaptive authentication can consider device posture, location, behavior, network characteristics, and transaction risk, but such signals are probabilistic and can create privacy or discrimination concerns.

2.3 Authorization models

Role-based access control (RBAC) assigns permissions to roles and users to roles. It is understandable and effective for stable organizational responsibilities, but role explosion can occur when many exceptions are added.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might permit a clinician to read records only when the clinician is assigned to the patient, the purpose is treatment, the device is managed, and the request occurs within an approved context.

Relationship-based access control (ReBAC) makes relationships central, such as “a project member may read a project document.” It is useful for collaboration systems and graph-shaped permissions.

A mature architecture may combine these models. Regardless of model, important principles include least privilege, separation of duties, deny-by-default, explicit purpose limitation, time-bounded access, and regular entitlement review. Authorization decisions should be centralized enough to remain consistent but distributed enough to meet availability and latency requirements.

2.4 Policy enforcement and consistency

A common policy architecture separates the policy administration point, policy decision point, and policy enforcement point. Enforcement points protect APIs, message brokers, databases, and administrative interfaces. Decision points evaluate requests using identity, resource metadata, environmental context, and policy version.

Caching authorization decisions improves performance but introduces staleness. A revoked privilege may remain effective until a cache expires. Designers must therefore define maximum acceptable staleness, revocation mechanisms, emergency deny controls, and fail-open or fail-closed behavior. Fail-closed improves security during uncertainty but may harm availability; fail-open may preserve service while creating unacceptable exposure. The correct choice depends on the protected asset and safety consequences.

3. Zero-Trust Networking

Zero trust is an architectural approach, not a product or a claim that trust can be eliminated. Its premise is that network location does not establish trust. Every access request should be evaluated using explicit identity, device and workload posture, resource sensitivity, requested action, and current context. Verification is continuous rather than performed only at initial network entry.

A zero-trust design commonly includes:

• strong human and workload identity;
• granular policy enforcement near protected resources;
• mutual authentication between services;
• micro-segmentation and minimized east-west communication;
• continuous telemetry and risk assessment;
• short-lived credentials and rapid revocation;
• protected administrative pathways;
• explicit inventory of assets, dependencies, and data flows.

Zero trust does not mean “authenticate every packet” without regard to operational reality. Excessive prompts, weak policy quality, or unavailable identity infrastructure can encourage workarounds. Effective implementation begins with high-value applications and privileged paths, then expands through measured policy refinement.

A zero-trust request can be represented conceptually as:

`Permit = Policy(subject, action, resource, context, risk)`

This is a policy function, not a universal mathematical formula. Its output must be determined by organizational rules and risk tolerances. Context may include device health, time, location, workload provenance, and recent behavior. Because risk signals can be wrong, high-impact decisions should include safeguards, human review, and an appeal or recovery process.

4. Encryption and Key Management

4.1 Encryption objectives

Encryption transforms plaintext into ciphertext using a key so that unauthorized parties cannot understand the content. Encryption in transit protects communication channels; encryption at rest protects stored data; and encryption in use seeks to limit exposure while data is processed, using techniques such as trusted execution environments or privacy-enhancing computation.

Authenticated encryption is generally preferred because it provides confidentiality and integrity together. A secure design must also protect metadata, endpoint memory, logs, backups, and temporary files; encrypting only the primary database is insufficient.

Symmetric encryption uses the same secret key for encryption and decryption and is efficient for bulk data. Public-key cryptography uses a key pair and supports authentication, key establishment, and digital signatures, but is computationally more expensive. In practice, systems use hybrid designs: public-key mechanisms establish or protect a symmetric session key, and symmetric authenticated encryption protects the data stream.

Encryption does not solve authorization. A stolen decryption key, compromised endpoint, or overly privileged service can still expose plaintext. Nor does encryption automatically ensure privacy: identifiable data may remain inferable from access patterns, timing, or metadata.

4.2 Key-management lifecycle

Key management includes generation, registration, distribution, activation, rotation, backup, recovery, revocation, archival, and destruction. Keys should be generated using approved cryptographic randomness, stored in protected systems such as hardware security modules where justified, and separated according to environment and purpose. Development, testing, and production keys must not be shared.

Key hierarchy reduces operational complexity. A key-encryption key can protect data-encryption keys, allowing data keys to be rotated or rewrapped without re-encrypting all data. Envelope encryption follows this pattern: a data key encrypts content, while a higher-level key protects the data key. Access to key-use operations should be separately authorized and audited.

Rotation is not a substitute for incident response. If compromise is suspected, organizations need revocation, containment, re-encryption or rewrapping, investigation of historical use, and a plan for unavailable keys. Key loss can cause permanent data loss; excessive recoverability can undermine confidentiality. This is a governance trade-off requiring documented recovery objectives and separation of duties.

5. Software Supply-Chain Security

Distributed applications depend on operating systems, libraries, container images, build tools, infrastructure modules, SaaS providers, and firmware. A vulnerability or malicious modification in one dependency can propagate through thousands of deployments. Supply-chain security therefore covers provenance, integrity, vulnerability management, and organizational accountability.

Important controls include:

• maintaining an inventory and software bill of materials (SBOM);
• pinning and verifying dependency versions;
• using signed artifacts and trusted build provenance;
• isolating and protecting build systems;
• applying reproducible or independently verifiable builds where feasible;
• scanning source code, dependencies, images, infrastructure definitions, and secrets;
• reviewing maintainer and vendor risk;
• restricting package repositories and build permissions;
• monitoring vulnerability advisories and exploitability;
• preparing rapid update and rollback procedures.

Signatures prove that an artifact was signed by a particular key; they do not prove that the signer is benevolent or that the software is free of vulnerabilities. Verification must therefore include provenance, policy, testing, and runtime controls. A vulnerability should be prioritized by exposure, exploitability, affected privilege, compensating controls, and business impact rather than by severity score alone.

Third-party contracts should address security responsibilities, notification timelines, audit rights, data handling, subcontractors, service continuity, deletion, and exit assistance. Concentration risk also matters: dependence on one cloud, identity provider, or package ecosystem can create systemic vulnerability.

6. Privacy, Data Sovereignty and Governance

Privacy is not equivalent to secrecy. Privacy concerns appropriate collection, use, disclosure, retention, inference, and control over personal information. A system may encrypt data yet violate privacy by collecting excessive information, retaining it indefinitely, or using it for an unrelated purpose.

Privacy-by-design principles include data minimization, purpose limitation, storage limitation, accuracy, user transparency, access and correction rights, appropriate security, and accountability. Technical practices include pseudonymization, tokenization, aggregation, differential privacy where suitable, local processing, access separation, and deletion workflows. Pseudonymization reduces direct identification but does not make data anonymous if re-identification remains reasonably possible.

Data sovereignty concerns the authority of a jurisdiction over data, processing, access, and infrastructure. Requirements may arise from law, contract, national security policy, sector regulation, or organizational risk. A cloud region label alone does not establish sovereignty: support personnel, backup locations, encryption-key control, metadata, and lawful-access mechanisms must also be examined.

Governance should define data ownership, stewardship, classification, retention, acceptable use, cross-border transfer conditions, incident notification, and decision rights. A data inventory and lineage map are foundational. They should identify what data exists, where it flows, why it is processed, who can access it, and when it should be deleted.

Privacy impact assessments are valuable before deploying systems that process sensitive or large-scale personal data. They should examine necessity, proportionality, affected groups, foreseeable misuse, residual risk, alternatives, and mitigation. Privacy engineering should be integrated into architecture, not left to legal review after implementation.

7. Auditability, Monitoring and Incident Response

Auditability is the capacity to reconstruct relevant events and decisions with sufficient reliability. Logs should record identity, action, resource, timestamp, outcome, source, policy version, and correlation identifier where appropriate. Time synchronization improves analysis, but timestamps should not be treated as perfectly authoritative in distributed systems. Event ordering may require sequence numbers, causal metadata, or reconciliation of multiple sources.

Logs are themselves sensitive data. They may contain identifiers, query contents, tokens, location information, or health and financial details. Logging should therefore apply minimization, access control, integrity protection, retention limits, and secure transmission. Secrets and unnecessary personal data must not be recorded.

Responsible monitoring balances security value against intrusiveness. Organizations should define a legitimate purpose, notice where required, proportional scope, retention period, access restrictions, and review process. Monitoring employees or users continuously without safeguards can chill legitimate activity and produce discriminatory profiling. Automated anomaly detection should support investigation rather than be treated as unquestionable evidence.

Incident response includes preparation, detection, analysis, containment, eradication, recovery, notification, and lessons learned. Distributed incidents require attention to blast radius, identity compromise, dependency propagation, regional failover, evidence preservation, and communication across organizational boundaries. Post-incident reviews should examine systemic causes rather than merely blame an individual operator.

8. Compliance, Ethics and Accountability

Regulatory compliance is a baseline, not a complete security strategy. Applicable obligations vary by sector and jurisdiction and may address personal data, financial records, health information, critical infrastructure, consumer protection, breach notification, or operational resilience. A responsible compliance program maps obligations to controls, evidence, ownership, testing, and remediation. It should avoid “checkbox compliance,” in which documentation substitutes for effective risk reduction.

Ethical governance asks questions that technical legality may not answer:

• Is the purpose legitimate and proportionate?
• Who benefits and who bears the risk?
• Can affected people understand and challenge the decision?
• Does the system amplify inequality or exclude vulnerable groups?
• Are users coerced into excessive data disclosure?
• Can the system be repurposed for surveillance or repression?
• Is there a meaningful human responsibility for automated outcomes?

AI-enabled distributed systems intensify these concerns. Models may infer sensitive attributes, encode historical bias, or make decisions that are difficult to explain. Governance should specify data provenance, evaluation populations, performance limits, human oversight, model-change approval, security testing, and mechanisms for correction and appeal. Privacy-preserving machine learning can reduce exposure but does not eliminate risks of bias, inference, or misuse.

Accountability requires named owners, documented decisions, independent review where appropriate, and effective remedies. “The algorithm decided” is not an acceptable allocation of responsibility.

9. An Integrated Security-Governance Framework

A practical program can be organized into six connected activities:

1. Discover: inventory identities, services, data, dependencies, jurisdictions, and trust relationships.

2. Classify: determine sensitivity, criticality, privacy impact, and regulatory obligations.

3. Protect: implement least privilege, segmentation, encryption, secure development, resilient key management, and supplier controls.

4. Detect: collect proportionate telemetry, validate policy behavior, and monitor for compromise or misuse.

5. Respond: maintain tested procedures for credential revocation, isolation, communication, recovery, and reporting.

6. Govern and improve: review metrics, conduct assessments, learn from incidents, and revise policy.

Useful indicators include privileged-access review completion, percentage of workloads with strong identity, mean time to revoke compromised credentials, dependency coverage by SBOM, unresolved critical vulnerabilities, encryption-key recovery test success, unauthorized-access incidents, and privacy-request response performance. Metrics must be interpreted carefully: a low incident count may indicate poor detection rather than strong security.

Governance should use defense in depth. Preventive controls reduce likelihood; detective controls improve discovery; responsive controls limit duration and impact; corrective controls prevent recurrence. Independent assurance, penetration testing, threat modeling, tabletop exercises, and supplier assessments provide evidence, but none replaces architectural discipline.

10. Illustrative Case: A Cross-Border Health Analytics Platform

Background

A fictional hospital network, MedData Alliance, wants to provide researchers with analytics over records held in hospitals across three countries. The platform uses cloud storage, containerized services, an external identity provider, and machine-learning workloads. Researchers require aggregate results, while clinicians require patient-level access for treatment.

Problem

The initial design places replicated records in one cloud region, uses shared service credentials, grants researchers broad database access, and stores detailed request logs indefinitely. The design creates risks involving cross-border transfer, insider misuse, credential compromise, re-identification, and unclear accountability.

Analysis

The data is highly sensitive and has different legal and contractual constraints across jurisdictions. A single global authorization role cannot represent the distinction between treatment, operations, and research. Replication and backups create additional locations that must be governed. Detailed logs improve investigation but may themselves expose patient information. Machine-learning outputs may permit re-identification through small-cell results or linkage with external datasets.

Approach and solution

MedData Alliance first creates a data-flow and processing inventory, classifies records, and appoints data owners and stewards. Patient-level data remains within approved jurisdictions where possible; researchers receive approved aggregates or controlled de-identified datasets. Cross-border transfers require documented legal and governance review.

Clinicians authenticate with phishing-resistant multifactor credentials. Services use short-lived workload identities and mutual authentication. ABAC and relationship rules restrict access according to clinician assignment, treatment purpose, jurisdiction, device posture, and emergency procedures. Emergency access is time-limited, prominently logged, and reviewed afterward.

The platform uses envelope encryption with separate keys by jurisdiction and environment. Key-use operations are logged, protected by hardware-backed services, and subject to dual control for sensitive administrative actions. Build pipelines generate SBOMs, verify signed artifacts, and prevent unapproved images from deployment.

Researchers access a governed analysis environment rather than raw production databases. Queries are reviewed for purpose and disclosure risk; small groups are suppressed or aggregated. Logs record identities, purposes, policy versions, and outcomes while excluding unnecessary clinical content. A retention schedule deletes or archives data and logs according to documented requirements.

Outcome

The revised design reduces unnecessary data movement, narrows privileges, improves incident investigation, and makes responsibility visible. It does not eliminate risk: re-identification, provider compromise, model inference, and availability failures remain possible. Continuous assessment and independent review are therefore retained.

Learning points

The case demonstrates that security architecture, privacy governance, identity, cryptography, supply-chain controls, and ethics are interdependent. Encryption cannot compensate for excessive authorization; compliance cannot compensate for poor identity lifecycle management; and analytics value must be balanced against the rights and safety of affected individuals.

11. Challenges and Limitations

Security controls create cost, latency, operational complexity, and possible failure modes. Centralized identity can become a high-value target and an availability dependency. Fine-grained authorization may be difficult to explain or test. Encryption can complicate search, analytics, backup recovery, and lawful access. Strong privacy controls may reduce data utility. Immutable logs can preserve inaccurate or harmful information unless correction and access governance are designed.

Distributed organizations also face fragmented ownership. A platform team may control infrastructure, an application team may control policy, a vendor may control a dependency, and legal teams may interpret obligations differently. Effective governance requires shared standards, clear escalation paths, practical reference architectures, and executive support.

No framework guarantees security. Threats evolve, controls fail, insiders misuse legitimate access, and previously harmless data can become sensitive when combined. Mature organizations therefore treat security and governance as continuous learning disciplines.

12. Best Practices

• Establish authoritative inventories of identities, assets, data, dependencies, and jurisdictions.
• Use phishing-resistant multifactor authentication for privileged and high-risk access.
• Give workloads distinct, short-lived identities rather than shared static secrets.
• Enforce least privilege, separation of duties, purpose limitation, and periodic review.
• Treat every network as potentially hostile; authenticate and authorize near resources.
• Use authenticated encryption and manage keys through a documented lifecycle.
• Maintain SBOMs, verify provenance, secure build pipelines, and rehearse emergency updates.
• Minimize personal data in application stores, logs, analytics, and backups.
• Test revocation, recovery, incident response, and key restoration rather than merely documenting them.
• Assess suppliers and concentration risk, including exit and continuity plans.
• Make monitoring transparent, proportionate, access-controlled, and time-limited.
• Assign accountable owners for automated and human decisions, with appeal and remediation paths.
• Use compliance mappings as evidence of control operation, not as a substitute for risk analysis.

Chapter Summary

Distributed security depends on more than perimeter defense. Identity, authentication, authorization, and accountability form the principal control plane for users, services, devices, and organizations. Zero-trust architecture removes implicit trust based on network location and combines strong identity, contextual policy, segmentation, and continuous verification.

Encryption protects data in transit and at rest, but effective security also requires disciplined key generation, storage, rotation, revocation, recovery, and destruction. Software supply-chain security addresses the provenance and integrity of dependencies, build systems, artifacts, and suppliers. Privacy requires appropriate collection, purpose limitation, minimization, retention, transparency, and control; data sovereignty requires analysis of jurisdictions, processing, support access, backups, and keys.

Auditability and responsible monitoring provide evidence while preserving proportionality and privacy. Compliance establishes obligations and evidence, whereas ethics addresses legitimacy, fairness, human impact, accountability, and misuse beyond minimum legal requirements. The integrated approach is continuous: discover, classify, protect, detect, respond, and improve. In postgraduate practice, the key skill is evaluating technical controls together with operational, legal, organizational, and societal consequences.

Key Terms

Authentication: Verification of the identity of a user, service, device, or workload.

Authorization: Determination of what an authenticated principal may do.

Accountability: Ability to attribute actions and decisions to responsible principals.

Zero trust: Security approach that grants no implicit trust based on network location.

Federated identity: Acceptance of identity assertions issued by another trusted domain.

RBAC: Access control based on organizational roles.

ABAC: Access control based on subject, resource, action, and environmental attributes.

ReBAC: Access control based on relationships among principals and resources.

Least privilege: Granting only the authority required for an approved purpose.

Authenticated encryption: Encryption that provides confidentiality and integrity protection.

Envelope encryption: Protection of data-encryption keys by a higher-level key-encryption key.

Key lifecycle: Generation, use, rotation, recovery, revocation, archival, and destruction of keys.

SBOM: Inventory of software components and dependencies in an artifact or system.

Data sovereignty: Jurisdictional authority and control applicable to data and its processing.

Pseudonymization: Replacing direct identifiers while retaining a separately controlled linkage capability.

Data minimization: Collecting and retaining no more personal data than necessary.

Auditability: Capacity to reconstruct relevant actions, decisions, and events reliably.

Privacy impact assessment: Structured evaluation of privacy risks, necessity, proportionality, and mitigations.

Separation of duties: Dividing sensitive responsibilities so one person or process cannot abuse complete control.

Supply-chain security: Protection of software dependencies, suppliers, build processes, and artifacts.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization and accountability.

2. Why is network location insufficient as a trust signal in a distributed system?

3. What is envelope encryption, and why is it operationally useful?

4. Why does encryption alone not guarantee privacy?

5. Identify three properties of responsible security monitoring.

Long Answer Questions

1. Compare RBAC, ABAC, and ReBAC, including their strengths and limitations in a distributed enterprise.

2. Explain the identity, policy, segmentation, and monitoring components of a zero-trust architecture.

3. Describe a complete cryptographic key-management lifecycle and discuss the consequences of key loss or compromise.

4. Develop a software supply-chain security program for a containerized cloud platform.

5. Explain how privacy, data sovereignty, auditability, regulatory compliance, and ethics should be integrated into governance.

Analytical / Application Questions

1. A company discovers that a revoked administrator token remains valid in several regional policy caches for 20 minutes. Analyze the security and availability trade-offs and propose controls.

2. Design an access and privacy architecture for a multinational research platform that processes sensitive personal data but must provide aggregate analytics to external researchers.

3. A machine-learning service denies access to a minority group at a higher rate, although its authentication and authorization logs show no technical errors. Develop an investigation, governance, remediation, and accountability plan.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authentication from authorization?

A. Authentication verifies identity; authorization determines permitted actions.

B. Authentication encrypts data; authorization decrypts data.

C. Authentication records events; authorization deletes logs.

D. Authentication creates backups; authorization restores services.

Correct Answer: A. Authentication verifies identity; authorization determines permitted actions.

Question 2

Which control is most consistent with a zero-trust architecture?

A. Allowing all internal traffic after VPN login

B. Trusting services because they are in the same subnet

C. Evaluating identity, context, and policy near the protected resource

D. Disabling authentication for low-latency service calls

Correct Answer: C. Evaluating identity, context, and policy near the protected resource

Question 3

What is the principal purpose of envelope encryption?

A. To replace all authorization policies

B. To protect data-encryption keys with a higher-level key

C. To make plaintext publicly searchable

D. To eliminate the need for key rotation

Correct Answer: B. To protect data-encryption keys with a higher-level key

Question 4

Which statement about digital signatures is correct?

A. They prove that software has no vulnerabilities

B. They guarantee that the signer is trustworthy

C. They provide evidence of artifact origin and integrity when verified

D. They make encryption unnecessary

Correct Answer: C. They provide evidence of artifact origin and integrity when verified

Question 5

Which access-control model evaluates attributes of the subject, resource, action, and environment?

A. RBAC

B. ABAC

C. MAC address filtering

D. Static password control

Correct Answer: B. ABAC

Question 6

Why can pseudonymized data still present privacy risk?

A. It cannot be encrypted

B. It may be re-identified using linkage information or other datasets

C. It is always publicly available

D. It prevents all access logging

Correct Answer: B. It may be re-identified using linkage information or other datasets

Question 7

Which practice best supports software supply-chain security?

A. Using unverified dependencies with the newest version number

B. Sharing production build credentials among developers

C. Maintaining an SBOM and verifying artifact provenance

D. Disabling vulnerability notifications to reduce noise

Correct Answer: C. Maintaining an SBOM and verifying artifact provenance

Question 8

What is a key concern with detailed security logs?

A. They can never support investigations

B. They may contain sensitive personal data and therefore require protection

C. They automatically prevent insider misuse

D. They eliminate the need for incident response

Correct Answer: B. They may contain sensitive personal data and therefore require protection

Question 9

Which statement best describes data sovereignty?

A. Data is controlled only by the application developer

B. Data is subject to the authority and requirements of relevant jurisdictions

C. Data sovereignty means that data must never be encrypted

D. Data sovereignty applies only to public, non-sensitive information

Correct Answer: B. Data is subject to the authority and requirements of relevant jurisdictions

Question 10

Why is compliance not equivalent to complete security?

A. Compliance controls are always technically ineffective

B. Compliance addresses obligations and evidence but may not cover every organizational risk

C. Security never requires governance

D. Compliance prohibits incident response testing

Correct Answer: B. Compliance addresses obligations and evidence but may not cover every organizational risk