Security, Privacy and Trust Architecture

Introduction

Enterprise architecture is incomplete when it describes business capabilities, applications, data, and technology without explaining how those assets will be protected and trusted. Security, privacy, and trust architecture provides the structures, principles, controls, and decision processes through which an enterprise manages exposure to harm while continuing to deliver business value.

Modern enterprises operate across cloud platforms, mobile devices, software-as-a-service providers, application programming interfaces, data exchanges, operational technology, and remote work environments. Traditional security models assumed that a defensible perimeter could be established around a corporate network. That assumption is increasingly invalid. Users, workloads, devices, and data may be located anywhere, and legitimate credentials can be compromised. Consequently, contemporary architecture emphasizes identity, continuous verification, least privilege, resilience, privacy engineering, and accountability.

Security is concerned primarily with protecting confidentiality, integrity, and availability. Privacy concerns the lawful, fair, transparent, and responsible use of information about identifiable or reasonably identifiable people. Trust is the justified confidence that an entity, system, process, or artifact will behave according to an accepted policy or expectation. These concerns overlap but are not identical: a system can be secure yet use personal data unfairly, and a privacy-compliant system can still be unavailable during an attack.

This chapter develops a security and privacy architecture suitable for postgraduate analysis and practice. It connects zero trust, identity and access management, threat modeling, technical and administrative controls, encryption, secure software supply chains, risk governance, regulation, and ethics.

Learning Objectives

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

1. Explain the relationship between security, privacy, trust, risk, and enterprise architecture.
2. Apply zero-trust principles to users, devices, workloads, networks, and data.
3. Design an identity and access management capability using authentication, authorization, federation, and lifecycle controls.
4. Perform a structured threat-modeling exercise and select proportionate controls.
5. Distinguish preventive, detective, corrective, deterrent, and compensating controls.
6. Evaluate encryption, key management, logging, monitoring, and resilience decisions.
7. Analyze software and cloud supply-chain risks.
8. Integrate regulatory, ethical, and privacy-by-design requirements into architecture decisions.
9. Critically evaluate security architecture trade-offs through an applied case.

1. The Architectural Problem: Security, Privacy, and Trust

1.1 Security objectives

The classical security triad is the CIA model:

• Confidentiality: information is disclosed only to authorized parties.
• Integrity: information and systems remain accurate, complete, and protected from unauthorized alteration.
• Availability: authorized users can access information and services when required.

The triad is useful but not sufficient for enterprise architecture. Additional properties include authenticity, accountability, non-repudiation, resilience, and safety. Authenticity concerns whether an entity or message is genuine. Accountability links actions to responsible identities and evidence. Resilience is the ability to withstand, recover from, and adapt to disruption. Safety addresses unacceptable physical or societal harm, particularly in industrial, healthcare, transport, and artificial-intelligence systems.

Security objectives can conflict. Strong authentication may reduce usability; extensive logging may improve accountability while increasing privacy risk; aggressive data retention may support investigation but violate data-minimization requirements. Architecture is therefore a process of risk-informed optimization rather than the pursuit of absolute security.

1.2 Privacy as an architectural concern

Privacy is not equivalent to secrecy. Privacy includes control over collection, purposes, use, disclosure, retention, access, correction, and deletion of personal information. A privacy architecture should ask:

• What personal data is collected?
• For what specific purpose is it processed?
• Is the collection necessary and proportionate?
• Who can access it, and under what conditions?
• How long is it retained?
• Where is it transferred or stored?
• Can individuals exercise applicable rights?
• What happens when the data is inaccurate, misused, or exposed?

Privacy laws differ by jurisdiction, but widely recurring principles include lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, security, and demonstrable accountability. An enterprise must identify which laws apply according to the people affected, the location of processing, the sector, and the nature of the data.

1.3 Trust and assurance

Trust should not be treated as an unexamined assumption. In architecture, trust is established through evidence, policy, verification, and enforceable relationships. Evidence may include a valid certificate, a signed software artifact, a device-attestation result, an audit record, a successful control test, or a contractual assurance from a supplier.

A trust decision should be contextual. A device that is trusted to read a public website may not be trusted to administer a payment database. Similarly, a supplier’s certification may provide useful assurance but does not eliminate the customer’s responsibility to understand its own risk. Trust is therefore better represented as a continuously evaluated relationship than as a permanent status.

2. Security and Privacy Architecture Principles

A coherent architecture uses principles to guide decisions across projects. Important principles include the following.

Defense in depth

Protection should be distributed across identity, endpoints, networks, applications, data, personnel, and operations. If one control fails, other controls should limit the consequences. Defense in depth is not the same as indiscriminate duplication: overlapping controls should address different failure modes and should be operationally maintainable.

Least privilege and separation of duties

A subject should receive only the permissions necessary for an approved task and only for the necessary duration. Separation of duties prevents a single person or process from completing a sensitive transaction without independent review. These principles reduce the impact of stolen credentials and insider misuse.

Secure and privacy by design

Security and privacy requirements should be established during business and solution design, not added after implementation. Architectural options should be evaluated for attack resistance, data minimization, transparency, accessibility, and operational feasibility.

Fail securely and assume compromise

When a control fails, the default outcome should not grant unintended access. Systems should also be designed on the assumption that some credentials, endpoints, dependencies, or services will eventually be compromised. This assumption encourages segmentation, rapid detection, recovery, and blast-radius reduction.

Simplicity and explicitness

Unnecessary complexity creates configuration errors and makes verification difficult. Policies should be explicit, interfaces should have clear trust boundaries, and security responsibilities should be assigned to named roles.

Accountability and continuous improvement

Architectural decisions, exceptions, data uses, and control performance should be recorded. Security architecture is not a one-time project: threats, regulations, technologies, and business processes change.

3. Zero Trust Architecture

Zero trust is an architectural approach in which no user, device, workload, or network location receives implicit trust. Access is granted only after evaluating identity, policy, resource sensitivity, request context, and risk. NIST Special Publication 800-207 describes zero trust as a shift from static network perimeters toward protection of resources and continuous evaluation.

A practical zero-trust policy decision can be represented conceptually as:

Here, subject is a user, service, or process; device describes the requesting endpoint; resource is the target asset; action is the requested operation; context includes time, location, network, and transaction information; policy specifies organizational rules; and risk represents the assessed likelihood and consequence of misuse. This is a conceptual policy function, not a universal numerical formula. Its implementation depends on the organization’s identity, telemetry, policy engine, and risk model.

Core zero-trust practices

1. Verify explicitly. Authenticate and authorize using relevant signals rather than network location alone.
2. Use least privilege. Limit scope, permissions, and duration.
3. Assume breach. Segment resources, monitor continuously, and minimize blast radius.
4. Protect all communication. Use authenticated and appropriately encrypted connections.
5. Collect and use telemetry. Monitor identity, endpoint, application, network, and data events.
6. Automate policy decisions where appropriate. Automation should be explainable, tested, and subject to human oversight for high-impact decisions.

Zero trust does not mean that every request must be manually approved, nor does it require a particular vendor product. It is an architecture and operating model. A mature implementation usually includes centralized or federated identity, strong authentication, device posture assessment, micro-segmentation, application-level authorization, continuous monitoring, and automated response.

4. Identity and Access Management

Identity and access management (IAM) governs digital identities and their permissions throughout their lifecycle. It includes identity proofing, authentication, authorization, federation, privileged access, provisioning, review, and deprovisioning.

4.1 Identity lifecycle

A sound lifecycle includes:

1. Joiner: establish an identity and assign initial access based on role and business need.
2. Mover: reassess access when a person changes position, project, location, or responsibility.
3. Leaver: promptly disable accounts, revoke tokens, recover devices, and transfer business records.
4. Periodic review: require managers or resource owners to confirm that access remains necessary.

Lifecycle automation reduces orphaned accounts and inconsistent permissions, but automated decisions require accurate authoritative sources, exception handling, and auditability.

4.2 Authentication and federation

Authentication establishes confidence in an identity. Authentication factors are commonly classified as:

• knowledge, such as a password;
• possession, such as a hardware security key; and
• inherence, such as a biometric characteristic.

Multi-factor authentication combines distinct factor categories. Two passwords are not two independent factors. Phishing-resistant methods, including appropriately implemented public-key credentials, are generally stronger than one-time codes transmitted through vulnerable channels.

Federated identity allows one identity provider to issue assertions or tokens accepted by other services. Federation can improve usability and centralize policy, but it creates concentration risk: compromise of the identity provider may affect many relying parties. Trust relationships, token audience, signing-key protection, clock handling, logout behavior, and account recovery must be designed explicitly.

4.3 Authorization models

Common authorization models include:

RBAC is understandable but can produce role explosion. ABAC is expressive but requires reliable attributes and policy governance. In practice, hybrid approaches are common: roles provide a baseline, while attributes and context constrain or extend access.

Privileged access should use separate administrative identities, just-in-time elevation, approval for sensitive actions, session recording where lawful and proportionate, and strong monitoring. Break-glass access may be necessary during emergencies, but it should be narrowly scoped, logged, reviewed, and tested.

5. Threat Modeling and Risk-Informed Design

Threat modeling is a structured method for identifying what can go wrong, why it might occur, and which controls reduce the risk. It should begin early and be updated when architecture, dependencies, or threat conditions change.

5.1 Modeling process

A practical process is:

1. Define business objectives and security or privacy requirements.
2. Inventory assets, data flows, actors, trust boundaries, and dependencies.
3. Identify threats, misuse cases, vulnerabilities, and potential harms.
4. Estimate likelihood and impact using an explicit scale.
5. Select controls and assign owners.
6. Validate residual risk and obtain an accountable decision.
7. Monitor assumptions and revisit the model.

Data-flow diagrams are particularly useful because they show where data crosses trust boundaries. Threat categories such as spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege provide a useful prompt, but they should not replace domain-specific analysis.

5.2 Risk analysis

A simple qualitative model represents risk as a combination of likelihood and impact:

Likelihood and impact may be ordinal categories rather than physical measurements. Therefore, the expression supports prioritization; it does not produce a universally comparable financial value unless the scales and assumptions have been defined. A quantitative expected-loss model can be used when credible estimates exist:

ALE is annualized loss expectancy, SLE is single-loss expectancy, and ARO is annual rate of occurrence. SLE should represent the estimated loss from one event, while ARO represents expected events per year. The model assumes that event frequency and loss estimates are meaningful and that the organization is not hiding important dependencies or correlated events. It is unsuitable for precise prediction when data is sparse or impacts are non-linear.

Risk analysis should include direct financial loss, regulatory exposure, safety consequences, operational disruption, privacy harm, reputational damage, and effects on vulnerable groups. A low-probability event may still require treatment when its impact is catastrophic or legally unacceptable.

6. Security Controls and Assurance

Controls are safeguards intended to prevent, detect, respond to, or recover from adverse events. They can also be categorized by nature:

• Administrative controls: policies, training, risk acceptance, contracts, and governance.
• Technical controls: authentication, encryption, firewalls, endpoint protection, and monitoring.
• Physical controls: locks, environmental protection, visitor management, and secure disposal.

By function, controls may be preventive, detective, corrective, deterrent, compensating, or directive. Effective architecture combines these categories. For example, a payment system may use preventive transaction limits, detective anomaly monitoring, corrective account suspension, and compensating manual review when an automated control is unavailable.

Control selection should consider effectiveness, coverage, cost, usability, operational resilience, and failure modes. A control that is routinely bypassed because it is unusable may provide less real protection than its design suggests. Control assurance includes design review, implementation testing, operational testing, independent assessment, and evidence retention.

Metrics should measure outcomes rather than merely activity. Useful indicators may include privileged-access review completion, time to revoke leavers, mean time to detect and contain incidents, percentage of critical dependencies with known versions, backup restoration success, and unresolved high-risk findings. Metrics require definitions and denominators; otherwise, comparisons can be misleading.

7. Cryptography and Key Management

Cryptography supports confidentiality, integrity, authentication, and non-repudiation-like evidence, although legal non-repudiation cannot be guaranteed by mathematics alone. Major functions include:

• Encryption: transforms plaintext into ciphertext using a key.
• Hashing: produces a fixed-length digest used for integrity checking; a secure hash is not encryption.
• Message authentication codes: provide integrity and authenticity when parties share a secret.
• Digital signatures: use asymmetric keys to support origin authentication and integrity verification.
• Key exchange: establishes shared secrets over an insecure channel.

Encryption in transit protects communications between endpoints; encryption at rest protects stored information. Neither prevents authorized misuse, compromised endpoints, poor key management, or disclosure through application behavior.

Key management is often more important than selecting a nominally strong algorithm. It includes generation, storage, distribution, rotation, backup, revocation, recovery, access control, destruction, and audit. Keys should be separated by environment and purpose, and high-value keys should be protected using hardware-backed or otherwise strongly controlled mechanisms where appropriate. Secrets must not be embedded in source code or ordinary configuration files.

Architects should plan for cryptographic agility. Algorithms, protocols, certificates, and key sizes may become unsuitable because of new attacks, implementation flaws, or advances in computing. Post-quantum migration planning is increasingly relevant for long-lived confidential data, although actual adoption must follow validated standards and implementation guidance.

8. Secure Software and Supply-Chain Architecture

Enterprise security depends on software produced by internal teams and external suppliers. Supply-chain risk includes malicious or compromised dependencies, vulnerable components, build-system compromise, counterfeit artifacts, opaque subcontracting, insecure update channels, and inadequate vendor recovery capability.

A secure software lifecycle should include:

1. security and privacy requirements;
2. architecture and threat modeling;
3. secure coding standards and peer review;
4. dependency identification and vulnerability management;
5. protected source repositories and branch controls;
6. reproducible or strongly controlled builds where feasible;
7. signed artifacts and provenance evidence;
8. automated testing, including security testing;
9. controlled deployment and rollback;
10. vulnerability disclosure, patching, monitoring, and retirement.

A software bill of materials (SBOM) records component identities and versions. It improves visibility but does not itself prove that software is secure. Provenance describes how an artifact was produced and by which trusted process. Organizations should combine SBOMs with vulnerability intelligence, supplier assurance, code-signing controls, build isolation, runtime monitoring, and contractual obligations.

Third-party risk management should assess not only confidentiality but also availability, concentration risk, jurisdiction, subcontractors, incident notification, data deletion, audit rights, business continuity, and exit feasibility. Cloud responsibility models must be understood precisely: a provider may secure the underlying infrastructure while the customer remains responsible for identities, configurations, data, and applications.

9. Privacy Engineering and Data Governance

Privacy engineering translates principles into system properties and operational practices. Techniques include:

• data minimization and selective collection;
• purpose-specific schemas and access controls;
• tokenization or pseudonymization;
• aggregation and de-identification, with residual re-identification risk assessed;
• retention schedules and automated deletion;
• consent and preference management where applicable;
• privacy notices and user-access mechanisms;
• separation of identifying data from analytical data;
• privacy impact assessments for high-risk processing.

Pseudonymization reduces direct identifiability but does not necessarily make data anonymous. If a separately held key or auxiliary information can reconnect records to individuals, privacy obligations may continue to apply. De-identification is also vulnerable to linkage attacks when multiple datasets are combined.

Data governance assigns ownership, stewardship, classification, quality responsibility, retention rules, access authority, and permitted uses. Classification should reflect sensitivity and harm, not merely technical storage location. Governance must address copies, backups, logs, test datasets, analytics environments, and derived data.

Artificial intelligence introduces additional concerns: training-data provenance, sensitive attributes, memorization, model inversion, prompt injection, unauthorized disclosure, discriminatory outcomes, and unclear accountability. Security controls for AI systems should be integrated with conventional IAM, data governance, supply-chain assurance, monitoring, and human oversight. Automated decisions affecting rights or opportunities require especially careful legal and ethical analysis.

10. Regulatory, Ethical, and Governance Alignment

Architecture must translate external obligations into testable requirements. Relevant sources may include data-protection legislation, sectoral requirements, contractual commitments, national cybersecurity rules, records obligations, payment standards, and organizational policy. Frameworks such as the NIST Cybersecurity Framework, NIST SP 800-53, ISO/IEC 27001, ISO/IEC 27701, and the CIS Controls can structure governance, but no framework automatically guarantees compliance.

A governance model should define:

• an accountable executive or risk owner;
• security and privacy architecture authorities;
• data owners and system owners;
• control operators and independent assurance roles;
• exception and risk-acceptance procedures;
• incident escalation and regulatory notification responsibilities;
• evidence, audit, and review requirements.

Ethical architecture asks whether a technically legal use is fair, necessary, transparent, and proportionate. Surveillance, biometric identification, behavioral profiling, employee monitoring, and predictive analytics may create power imbalances or disproportionate effects. Consent may be invalid where individuals lack a realistic choice. Security controls themselves should be accessible and should not unjustifiably exclude people with disabilities or limited connectivity.

Applied Case: Illustrative Health-Services Platform

Background

A regional health organization operates clinics, a patient portal, diagnostic systems, mobile applications, and cloud analytics. Clinicians need rapid access to records, while patients expect confidentiality. The organization also relies on external laboratories and a software supplier that provides appointment and messaging services.

Problem

An assessment identified shared clinical accounts, excessive standing privileges, unencrypted exports, incomplete supplier inventories, and inconsistent retention of patient messages. Remote clinicians connected through a network VPN, but access inside the network was largely trusted. The organization’s leadership wanted stronger protection without making urgent clinical work impractical.

Analysis

Threat modeling identified several high-impact scenarios: stolen clinician credentials, ransomware affecting diagnostic systems, supplier compromise, accidental disclosure through exports, and inappropriate access to records by insiders. Privacy analysis found that message histories and analytics extracts were retained longer than necessary. The most important architectural issue was not simply a missing firewall; it was the combination of weak identity lifecycle controls, broad authorization, excessive copies, and limited detection.

Approach and solution

The organization adopted a phased architecture:

1. Identity: individual accounts replaced shared accounts; phishing-resistant multi-factor authentication was introduced for privileged and remote access; joiner–mover–leaver integration was established with the human-resources system.
2. Authorization: clinicians received role-based baseline access constrained by clinic, treatment relationship, and purpose. Break-glass access was permitted for emergencies and automatically reviewed.
3. Zero trust: applications evaluated identity, device posture, resource sensitivity, and session context rather than relying on VPN location. Diagnostic systems were segmented from office and guest networks.
4. Data protection: exports were minimized, tokenized where possible, encrypted in transit and at rest, and governed by retention schedules. Keys were managed separately from data.
5. Monitoring: access to sensitive records, administrative actions, unusual downloads, and supplier connections was logged and correlated. Monitoring was designed with access restrictions and retention limits to reduce secondary privacy risk.
6. Supply chain: critical suppliers provided component inventories, incident-notification commitments, recovery evidence, and secure-update assurances. Software artifacts were verified before deployment.
7. Resilience: immutable backups and restoration exercises were introduced for essential systems, with manual clinical continuity procedures tested.

Outcome

The organization reduced standing privilege, improved visibility of sensitive access, and shortened account-revocation time. Clinical users retained emergency access but accepted greater accountability. The program did not eliminate risk: device compromise, insider misuse, supplier disruption, and errors remained possible. However, risk became more visible, bounded, and governable.

Learning points

The case demonstrates that security architecture is socio-technical. Technology alone cannot resolve unclear ownership, excessive data collection, poor processes, or conflicting clinical priorities. Zero trust, privacy engineering, IAM, supply-chain governance, and resilience must be designed as mutually reinforcing capabilities.

Challenges and Limitations

Security and privacy architecture has unavoidable limitations. Threat models depend on assumptions and may omit novel attacks. Risk estimates can create false precision when evidence is weak. Zero-trust implementations can become surveillance systems if telemetry is collected without purpose limitation and access controls. Micro-segmentation may increase operational complexity. Strong authentication can create accessibility and availability problems if recovery is poorly designed. Encryption cannot compensate for compromised endpoints or authorized misuse. Compliance evidence may demonstrate that a process exists without proving that it works.

Organizations also face legacy technology, skills shortages, fragmented ownership, mergers, incompatible jurisdictions, supplier concentration, and budget constraints. Architecture must therefore use prioritization, incremental migration, compensating controls, and explicit risk acceptance. The most mature organizations treat incidents and near misses as learning inputs rather than merely as grounds for blame.

Best-Practice Design Checklist

• Identify assets, data subjects, business processes, dependencies, and trust boundaries.
• Define security, privacy, safety, and availability requirements before selecting products.
• Use individual identities, strong authentication, least privilege, and timely deprovisioning.
• Treat network location as insufficient evidence of trust.
• Threat-model important changes and high-impact data flows.
• Protect data throughout its lifecycle, including copies, logs, backups, and test environments.
• Manage cryptographic keys as critical assets.
• Maintain software inventories, provenance evidence, vulnerability processes, and supplier exit plans.
• Monitor control effectiveness and test restoration, incident response, and break-glass procedures.
• Make accountability, accessibility, transparency, and proportionality explicit architectural criteria.
• Record residual risk, exceptions, owners, assumptions, and review dates.

Chapter Summary

Security, privacy, and trust architecture embeds protection and accountability into enterprise design. Security extends beyond the CIA triad to authenticity, accountability, resilience, and safety. Privacy requires purpose limitation, minimization, transparency, retention control, and responsible data governance. Trust should be established through evidence and continuously evaluated rather than assumed from network location or supplier reputation.

Zero trust protects resources through explicit verification, least privilege, continuous evaluation, and an assumption of compromise. IAM provides the foundation through identity lifecycle management, strong authentication, federation, authorization, and privileged-access control. Threat modeling connects assets and trust boundaries to threats, harms, controls, and residual risk. Controls should be layered, testable, proportionate, and supported by meaningful metrics.

Encryption is valuable only when algorithms, protocols, endpoints, and keys are properly managed. Secure supply-chain architecture requires component visibility, provenance, secure development, supplier governance, and recovery planning. Privacy engineering turns principles into system properties such as minimization, pseudonymization, retention enforcement, and individual transparency. Finally, regulation and ethics require accountable governance, fair treatment, accessibility, and scrutiny of high-impact uses such as surveillance and artificial intelligence.

Key Terms

Access control: Mechanisms and policies that determine whether a subject may perform an action on a resource.

Attribute-based access control: Authorization based on attributes of subjects, resources, actions, and context.

Availability: The property that authorized users can access systems and information when required.

Defense in depth: Use of multiple complementary safeguards so that one failure does not cause total compromise.

Federated identity: An arrangement in which one identity provider supplies authentication assertions accepted by another service.

Identity and access management: Governance and technology for identities, authentication, authorization, and access lifecycles.

Integrity: Protection of information and systems against unauthorized or improper alteration.

Least privilege: Granting only the minimum permissions necessary for an authorized task.

Multi-factor authentication: Authentication using factors from at least two distinct categories.

Privacy by design: Incorporating privacy requirements and safeguards into systems from the beginning.

Pseudonymization: Processing that reduces direct identifiability while allowing possible re-linkage using additional information.

Risk: The possibility of harm arising from uncertainty, commonly analyzed through likelihood and impact.

Security control: A safeguard designed to prevent, detect, respond to, or recover from adverse events.

Software bill of materials: An inventory of software components and their versions.

Threat modeling: A structured analysis of assets, trust boundaries, threats, vulnerabilities, harms, and controls.

Trust boundary: A point at which data, authority, or assumptions about security change.

Zero trust: An architecture that grants no implicit trust and evaluates access explicitly and continuously.

Key management: Processes for generating, protecting, distributing, rotating, revoking, and destroying cryptographic keys.

Review Questions

Short Answer Questions

1. Distinguish confidentiality, integrity, and availability.
2. Why is network location insufficient as the basis for trust in a zero-trust architecture?
3. What is the purpose of the joiner–mover–leaver identity lifecycle?
4. Explain the difference between encryption and hashing.
5. Why does an SBOM not, by itself, prove that software is secure?

Long Answer Questions

1. Explain how zero trust, IAM, segmentation, and monitoring operate together in an enterprise architecture.
2. Compare RBAC and ABAC, including their strengths, limitations, and suitable application contexts.
3. Describe a complete threat-modeling process and explain how it supports risk-informed control selection.
4. Discuss privacy-by-design principles for an enterprise analytics platform that processes personal data.
5. Evaluate the governance and ethical issues associated with artificial-intelligence systems that make decisions about individuals.

Analytical / Application Questions

1. An organization discovers that former contractors retain access to a cloud application and that administrators use shared accounts. Analyze the risks and propose a prioritized remediation architecture.
2. A supplier provides a critical software update but cannot provide component inventories or evidence of build integrity. Decide what assurance and compensating controls should be required before deployment.
3. Design a conceptual zero-trust access policy for a remote employee requesting access to a highly sensitive database from an unmanaged device. Identify the decision inputs, possible outcomes, and privacy implications of monitoring.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a zero-trust principle?

A. Users inside the corporate network are trusted automatically.

B. Access is granted based only on a user’s job title.

C. Each access request is evaluated explicitly using relevant context and policy.

D. A VPN makes all internal applications trusted.

Correct Answer: C. Each access request is evaluated explicitly using relevant context and policy.

Question 2

Which authorization model evaluates subject, resource, action, and contextual attributes?

A. Role-based access control

B. Attribute-based access control

C. Discretionary access control

D. Single sign-on

Correct Answer: B. Attribute-based access control

Question 3

What is the primary purpose of a software bill of materials?

A. To encrypt source code

B. To list software components and versions

C. To replace penetration testing

D. To provide user authentication

Correct Answer: B. To list software components and versions

Question 4

Which statement about pseudonymization is correct?

A. It always makes data anonymous.

B. It prevents all unauthorized access.

C. It reduces direct identifiability but may permit re-linkage using additional information.

D. It is the same as deleting personal data.

Correct Answer: C. It reduces direct identifiability but may permit re-linkage using additional information.

Question 5

In the expression ALE = SLE × ARO, what does ARO represent?

A. Annual rate of occurrence

B. Authorized risk objective

C. Average recovery operation

D. Annual response obligation

Correct Answer: A. Annual rate of occurrence

Question 6

Which control is primarily detective?

A. A firewall rule blocking unauthorized traffic

B. A security-awareness policy

C. An alert generated by monitoring unusual data downloads

D. A backup restoration procedure

Correct Answer: C. An alert generated by monitoring unusual data downloads

Question 7

Why is key management critical to an encryption architecture?

A. Encryption removes the need for access control.

B. Poorly protected keys can allow protected data to be decrypted.

C. Keys are only needed for hashing.

D. Key rotation eliminates all security risk.

Correct Answer: B. Poorly protected keys can allow protected data to be decrypted.

Question 8

Which event most directly represents a joiner–mover–leaver control failure?

A. A system uses a signed software artifact.

B. A former employee’s account remains active after departure.

C. A database backup is restored successfully.

D. A privacy notice is updated.

Correct Answer: B. A former employee’s account remains active after departure.

Question 9

What is a major limitation of qualitative risk matrices?

A. They cannot identify assets.

B. They always require financial loss data.

C. Ordinal scores can create an appearance of precision without comparable quantitative meaning.

D. They cannot support prioritization.

Correct Answer: C. Ordinal scores can create an appearance of precision without comparable quantitative meaning.

Question 10

Which practice best supports privacy by design?

A. Collecting all potentially useful data indefinitely

B. Using purpose limitation, minimization, retention controls, and transparency from the design stage

C. Relying exclusively on perimeter firewalls

D. Granting analysts unrestricted access to raw identifiers

Correct Answer: B. Using purpose limitation, minimization, retention controls, and transparency from the design stage