Identify Security Requirements

A stakeholder drops a 200-page standard on your desk and asks whether the new platform complies. Four questions settle that before a single control is chosen: who says this applies to us, does it reach this system, what exactly does it demand, and how would we prove it later. Governance, risk, and compliance (GRC) work at architect level begins with that discovery pass. The other page in this domain, Architecting for GRC, takes the finished requirement set as its input and designs the monitoring, reporting, auditability, and risk-treatment response; this page stops at knowing which obligations bind the architecture and how far they reach.

The four requirement families

Requirements on this objective arrive from four sources, and the rest of the page keeps these names:

• Standards and guidelines, running from cross-industry standards such as ISO/IEC 27001 and the NIST Cybersecurity Framework to industry-specific ones such as the payment card rules.
• Third-party and contractual obligations, covering supply chain, outsourcing, and partner agreements.
• Personal-data and privacy law, such as the General Data Protection Regulation (GDPR).
• Resilience requirements, the continuity and recovery duties the business imposes on itself.

One document can raise requirements in more than one family. A customer contract that also carries privacy terms is ordinary, so treat the families as a way of sorting requirements, not documents.

Assurance evidence, meaning the certificates, attestation reports, and product evaluations other parties hand you, is not a fifth family. It belongs to the evidence stage described below, and it gets its own section because reading its scope correctly is a distinct skill.

Binding authority comes first

A law, regulation, directive, or contract creates an obligation through the authority behind it, while a framework or guideline stays voluntary until an authority or an internal policy adopts it. That distinction is the most common failure point in requirement discovery. Teams cite a well-known framework as though publication made it mandatory, spend the budget on controls no assessor will ask about, and leave a genuine contractual duty unmet. The practical test is to ask who can penalize the organization for non-compliance, because the answer names the authority.

Internal policy sits on the mandatory side of that line. Applicable requirements include the organization's own policies and mission needs, so meeting an external minimum does not discharge a stricter internal baseline unless the authorized policy owner approves an exception or changes the policy.

From authority to evidence

Every family then runs the same five stages, which is why one model carries the whole page. The figure below traces them in order: name the binding authority, test whether it applies to this organization and this system, draw the scope boundary, allocate controls and owners, and retain the evidence that ties the result back to the source obligation.

One stage is explicitly not the architect's to perform. Security architects obtain authoritative readings of laws and regulatory conflicts from qualified legal and privacy stakeholders, then convert those readings into verifiable security and privacy requirements. Getting that division wrong produces an architecture defended by an engineer's opinion of a statute.

The takeaway holds for practice and for the exam: a requirement is usable only once you can state its authority, its applicability, its scope, its allocated controls, and its evidence. Anything missing one of the five is still an assumption.

This section covers the first family: the published standards, frameworks, and control catalogs an architect is expected to recognize, tell apart, and tailor.

Start with the distinction candidates lose most often. ISO/IEC 27001 specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS), and it is the certifiable management-system standard. ISO/IEC 27002 is the companion guidance describing the controls themselves, and an organization does not certify against it. Both numbers look interchangeable on an exam screen and are not.

The NIST Cybersecurity Framework (CSF) 2.0 works differently again. It supplies a technology-neutral taxonomy of cybersecurity outcomes and points to informative references^[1] for the practices and controls that achieve them, rather than prescribing an implementation. An architect tailors those outcomes to mission, sector, and risk appetite, so reading the CSF Core as a fixed control baseline misreads what the document is.

A control catalog is the third shape. NIST SP 800-53 provides a catalog of security and privacy controls that address requirements^[2] derived from missions and business functions, laws, executive orders, directives, regulations, policies, standards, and guidelines. The catalog exists to be scoped, tailored, and allocated. Selecting all of it is not a risk-based architecture, it is an unfunded wish list, and it buries the controls that actually address the organization's risk.

Publication	What it is	What the architect does with it
ISO/IEC 27001	Requirements for an ISMS; the certifiable standard	Establish the management system and define its scope
ISO/IEC 27002	Guidance describing information security controls	Use for control detail, never as the certification target
NIST CSF 2.0	Technology-neutral cybersecurity outcomes	Tailor outcomes to mission, sector, and risk appetite
NIST SP 800-53	Catalog of security and privacy controls	Scope, tailor, and allocate controls to the system

Crosswalks indicate relationships, not equivalence

Mappings between standards give a general indication of coverage, and the relationships they assert may be subjective and are rarely one to one. A mapped control is a hypothesis about coverage, so compliance is validated against the source requirement and its scope rather than inferred from the crosswalk. This bites hardest where one control set is claimed to satisfy several regimes at once, because a single mapping error then propagates into every claim built on it.

The takeaway is to identify the shape of the document in front of you, whether management-system standard, outcome framework, or control catalog, and then tailor rather than adopt.

Industry standards sit inside the standards and guidelines family, and they differ from the cross-industry ones mainly in how they bind: usually through contract rather than statute. Payment card rules are the example an ISSAP candidate is most likely to meet.

PCI DSS defines baseline technical and operational requirements designed to protect payment account data, which covers both cardholder data and sensitive authentication data. Its audience is every entity involved in payment card processing^[3], including merchants, processors, acquirers, issuers, and service providers, rather than only the business that takes the card at checkout. An architect who assumes the standard is a merchant concern will under-scope a processing or service-provider design.

What lands inside the scope boundary

Scope covers the system components that store, process, or transmit account data, plus components that can affect the security of the cardholder data environment (CDE). The phrase that decides most real scoping arguments is the second one. A jump host, a directory service, a patch server, or a monitoring agent with reach into the CDE is in scope even though no card number is ever written to it, because compromising it would affect the security of the environment that does hold the data.

Segmentation narrows that boundary only when its effectiveness is established and maintained. A VLAN drawn on an architecture diagram is not segmentation for scoping purposes; a segmentation control whose effectiveness has been verified, and is re-verified as the environment changes, is. Excluding a connected dependency by assertion invalidates both the control design and the compliance evidence resting on it.

The generalizable rule is worth more than the payment specifics: for any industry standard, find the protected data, then follow every component that touches it or can affect its security.

A supplier arrives at your design review carrying a certificate, an attestation report, and a datasheet quoting an assurance level, and asks you to accept all three as proof. Each is a bounded claim, and the boundary is the part that gets misread. This section covers how to read the kinds of assurance evidence an architect is handed, which is the evidence stage of the chain applied to somebody else's work rather than a requirement family of its own.

An ISO/IEC 27001 certificate provides independent confidence that the organization operates an ISMS conforming to the standard within the scope printed on the certificate. It is not a guarantee that every product, location, or information system is secure, and a certificate whose scope names one business unit says nothing about the rest.

A service provider assurance report carries the same lesson with more moving parts. Check the entity, the service, the location, the period covered, the exclusions, and the customer responsibilities the report assigns back to you. Current provider evidence never establishes that the customer's own configuration and retained controls are compliant, which is why an attestation is an input to your assessment rather than a substitute for it.

Common Criteria: what was evaluated, and how deeply

Under Common Criteria there are two documents worth separating. A Protection Profile (PP) states implementation-independent security requirements^[4] for a class of products, so it is reusable and describes a need. A Security Target (ST) identifies one particular target of evaluation (TOE) along with the functional and assurance requirements that target is evaluated against, so it describes a specific claim about a specific product.

Assurance depth is the second axis. An evaluation determines whether the defined target satisfies specified security properties at a stated depth of assurance, expressed as an Evaluation Assurance Level (EAL). A higher EAL buys more rigorous evaluation of the claim, not freedom from all vulnerabilities and not suitability for every operating environment. Selecting a product because it carries the highest EAL, without reading what its Security Target actually claims, is the trap the exam builds around this topic.

Evidence	What it establishes	What it does not establish
ISO/IEC 27001 certificate	An ISMS conforming to the standard within the certified scope	That any particular product or system is secure
Service provider attestation	Controls assessed for the named service, location, and period	That your configuration and retained controls comply
Protection Profile	Reusable requirements for a class of products	Any claim about a specific product
Security Target evaluation result	That the evaluated target met stated properties at a stated EAL	Absence of vulnerabilities, or fitness for every environment

In every row the pattern repeats: read the scope statement before the conclusion.

Outsourcing moves the work and never the accountability. This section covers the second family, the obligations that arrive through suppliers and contracts. An acquiring organization remains responsible for managing the risks and obligations^[5] attached to its own mission and information even when a supplier performs the activity, so the architecture allocates shared controls and evidence duties explicitly instead of assuming the provider's programme covers them.

Requirements flow down, notifications flow up

Controls implemented across the system life cycle frequently depend on prime suppliers (also called prime contractors) and their sub-tier suppliers. The contract therefore has to name which security, privacy, assurance, and reporting requirements pass down the supply chain. Without that flow-down, outsourcing depth quietly breaks the continuity of control, and the acquiring organization holds a prime supplier to a standard the prime supplier's own subcontractor never agreed to. The figure below shows the two directions that matter and who sits at each level.

Notification terms are the return path. An agreement states which incidents, vulnerabilities, component changes, or supply disruptions the supplier reports, to whom, and within what timeframe. Those terms are what make the acquiring organization's own response and regulatory reporting deadlines achievable. Without them, an acquiring organization with a 72-hour regulatory clock depends on a supplier who has agreed to no clock at all.

Assurance spans the relationship, not the purchase

Cybersecurity supply chain risk management (C-SCRM) applies risk-based due diligence and assessment before selection or acceptance, then continues with reviews and monitoring throughout performance. A one-time procurement questionnaire cannot address a later change of ownership, a new development location, a shift in subcontractors, or a vulnerability disclosed after award.

Provenance and component transparency

Provenance records track a component's origin, ownership, custody, and changes, which is what allows a component to be validated as genuine and unaltered. A software bill of materials (SBOM) adds visibility of software components for vulnerability and dependency analysis. Neither proves the components are secure. An SBOM is an inventory, and reading it as a product security certification is a distractor the exam uses more than once.

The takeaway is that every third-party requirement needs a named owner on both sides of the contract: what flows down, what reports back, and who holds the accountability that never moved.

Privacy obligations attach to data processing, and processing is a far longer list than storage. That single observation reorganizes most privacy architecture work.

Data processing covers collection, generation, transformation, use, disclosure, sharing, transmission, logging, retention, and disposal^[6], among other actions performed on data. Protecting the production database therefore addresses a fraction of the duty, because derived records, log entries, analytics extracts, test data sets, and backups carry the same obligations as the source table. Privacy architecture follows the data and the records derived from it through every lifecycle action.

Minimization is a requirement, not a preference

NIST guidance recommends minimizing the use, collection, and retention of personally identifiable information (PII) to what is strictly necessary^[7] for the mission or business purpose, and reviewing holdings periodically to confirm they are still needed. Encryption reduces the risk of disclosure but does not create a purpose, so encrypted data with no defined need is still data that should not have been retained.

Impact is contextual rather than a property of the field name. The confidentiality impact level of PII depends on identifiability, quantity, the sensitivity of individual data fields, context of use, obligations to protect, and access to and location of the data. The same element can be low impact in one system and high in another once it is combined with other fields or used for a more sensitive purpose.

Privacy risk is not a subset of security risk

Problems for individuals can arise from data processing that is entirely authorized and where confidentiality, integrity, and availability are intact. A security risk assessment focused on unauthorized access therefore cannot stand in for an analysis of purpose, predictability, autonomy, and the effects processing has on people. This is the distinction behind many privacy items: the scenario describes a system with no breach and a real privacy problem.

De-identification needs a re-identification analysis

Removing direct identifiers does not necessarily prevent records from being linked back to individuals through the remaining attributes or through external data sets. De-identification techniques and release controls^[8] are selected against the intended use and a credible re-identification threat, so declaring a data set anonymous because the name column was dropped is an assertion, not an analysis.

The takeaway is to trace the data, not the datastore: every lifecycle action is a place where a privacy requirement applies.

Under GDPR the controller determines the purposes and means of processing, and every duty in this section follows from holding that role. A controller here is an organization playing a legal role, not a security control, despite the shared word. The processor acts on the controller's documented instructions, which is why one event produces different obligations for each party.

GDPR's own reach is the applicability question that comes first. It can bind an organization that is not established in the EU where the processing relates to offering goods or services to people in the EU^[9] or to monitoring their behavior there, so physical location is not the test. The duties below are GDPR's; other privacy regimes set their own thresholds and timeframes, and the applicability analysis is what decides which set binds a given system.

Select and document a lawful basis before processing

Processing is lawful only when an Article 6 basis supports the purpose^[10]: consent, contract necessity, a legal obligation, vital interests, a public task, or a qualifying legitimate interest. The controller determines and documents that basis before processing begins and provides the required transparency to the data subject. A technical ability to use the data, or a business appetite for it, is not a lawful basis.

Consent is one of those six and not a universal prerequisite. Where it is the chosen basis it must be freely given, specific, informed, and unambiguous^[11], the controller must retain evidence that it was obtained, and withdrawal must be as easy as giving it and must stop further consent-based processing. Designing a system that can record consent but cannot honor a withdrawal fails the requirement.

Build privacy into the design and the defaults

Privacy by design and by default^[12] asks for appropriate technical and organizational safeguards to be integrated when the means of processing are determined and while processing runs. The default settings limit the amount of data collected, the extent of processing, the retention period, and accessibility to what each specified purpose requires, without depending on the individual to tighten a permissive default.

When a processor handles the data, the controller selects one providing sufficient guarantees and binds it with a written processing agreement^[13] covering subject matter, duration, nature and purpose, data types, obligations and rights, security, assistance, return or deletion at the end, and processing only on documented instructions. Delegating execution never relieves the controller of accountability for demonstrating compliant processing.

Rights are an architectural requirement

The rights of the data subject^[14] include information and access, rectification, erasure, restriction of processing, portability, objection, and safeguards concerning automated decision-making and profiling. Making them real means the architecture can locate data by subject, produce an intelligible copy, correct or delete records, restrict downstream use, export a portable form, propagate an objection to systems that already received the data, and govern automated decision workflows. Retrofitting this onto a design that cannot find one person's records across its stores is the expensive path, and it is the reason rights belong in requirement discovery rather than in a later compliance project.

Breach notification follows risk, recipient, and role

A processor notifies its controller without undue delay. A controller notifies the supervisory authority without undue delay^[15] and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where a high risk to individuals is likely, the controller also communicates the breach to the affected data subjects^[16] without undue delay, unless a stated exception applies, such as protection that renders the data unintelligible to anyone not authorized to access it. The figure below walks those branches in the order the decision is actually made.

The 72-hour clock is a frequent exam target, so note precisely what it qualifies: it bounds notification to the supervisory authority where feasible, not communication to individuals, which runs on the without-undue-delay standard and a high-risk trigger.

Recovery numbers come from the business, and the architecture is what meets them. Reversing that order produces a design whose failover capability nobody asked for and whose data loss nobody accepted.

The business impact analysis (BIA) determines process criticality and the impacts of an outage, identifies the resource requirements that support each process, and establishes recovery priorities^[17]. A general risk assessment feeds the BIA without replacing it: vulnerability severity ranks weaknesses, while the BIA ranks what the organization cannot operate without. Setting recovery order from scan severity is a recognizable wrong answer.

Three numbers, three different losses

Maximum tolerable downtime (MTD) is the total length of time a mission or business process can be disrupted without unacceptable harm. The recovery time objective (RTO) states how quickly a system or process must be restored after disruption. The recovery point objective (RPO) states the acceptable age of the data once restored, which is what sets backup or replication frequency. The relationship between them is the testable part: the RTO plus the time needed to recover work lost since the last recovery point must fit inside the MTD. The figure below places all three on one timeline around the disruption.

RTO and RPO bound different losses, and swapping them is one of the most common distractors on this objective. Time to restore service is RTO. Age of the restored data is RPO.

An alternate capability has to fail differently

Relocating processing or storage adds resilience only when the alternate capability has suitable capacity, dependencies, accessibility, and separation from the threats affecting the primary environment. Redundancy that shares a power feed, a network path, a control plane, or a flood plain with the primary is nominal: one credible event still takes both. The question to ask of any alternate site or region is which specific failures it does not share.

Resilience also means more than staying up. A resilient architecture anticipates that some preventive controls will fail, preserves essential functions even in a degraded state, and enables rapid recovery. Boundary protection alone does not address attacks, environmental disruption, or human error that penetrates or bypasses it, which is why continuity requirements sit beside preventive ones rather than behind them.

A regional data center goes dark overnight, and the on-call architect has five documents to choose between. Picking the wrong one wastes the first hour of an outage, and matching the situation to the right plan is a recurring exam item. This section covers which plan covers what, how execution is structured, and what actually counts as validation.

These are the plan types this objective expects you to tell apart, and NIST SP 800-34 distinguishes several more, including crisis communications and occupant emergency plans.

Plan	What it sustains or restores
Business continuity plan (BCP)	Mission and business processes during and after a disruption
Continuity of operations (COOP) plan	An organization's mission-essential functions, typically at an alternate site
Cyber incident response plan	The response to malicious cyber events
Disaster recovery plan (DRP)	Information system operations relocated after a major facility disruption
Information system contingency plan (ISCP)	An individual system, at its current or an alternate location

The scopes above come from NIST SP 800-34^[17], and an ISCP can operate on its own or underneath the broader plans. The distinction that decides most questions is breadth: a BCP is about business processes, a DRP is about relocating system operations after a facility event, and an ISCP is about one system.

Execution runs in three phases

Activation and notification applies the outage criteria, declares the plan, assesses the disruption, and mobilizes the affected parties. Recovery restores the prioritized capabilities using the selected strategy. Reconstitution validates recovered data, functionality, and controls, resumes normal operations, and formally deactivates the plan. The figure below shows the three phases in the order they run and what each one delivers.

Reconstitution is where candidates slip. Recovery is not complete when the service answers a request; it is complete when the restored system has been validated and formally returned to normal operation, which is also when the temporary controls introduced during recovery are retired.

Testing, training, and exercises are not interchangeable

Testing validates recovery capabilities, training prepares personnel for their assigned duties, and exercises reveal coordination and planning gaps under a scenario. A tabletop discussion produces useful findings about decision-making, and it does not provide the assurance of executing technical recovery in an operationally representative environment. When a question offers a walkthrough as evidence that failover works, that is the distractor.

Plans track material change

Contingency plans are reviewed on an organization-defined schedule and whenever significant changes affect systems, interconnections, suppliers, facilities, personnel, responsibilities, or organizational requirements. A material change can force updates to the BIA, the recovery priorities, the procedures, the contact lists, the standby agreements, and every controlled copy of the plan. A plan that documents a supplier or a site the organization no longer uses is not a resilience control, it is a document.

ISSAP items on this objective rarely ask you to recite a standard. They hand you a situation and ask what the architect does next, which means the winning skill is spotting which stage of the requirement chain the scenario is stuck at.

The framework-as-mandate stem. A scenario names a well-known framework and asks whether the organization must implement it. The correct answer establishes authority or applicability first. Distractors jump to implementing, certifying, or budgeting for the framework, which is exactly the behavior the binding-authority rule exists to prevent.

The accountability transfer. A service is outsourced, or a provider presents a certificate. Correct answers keep accountability with the organization, define the shared responsibility explicitly, and verify what the provider's evidence actually covers. Distractors treat the certificate or the contract as the end of the analysis.

The objectives swap. A stem gives a tolerable data loss and asks for the objective that expresses it, or gives a restoration deadline and asks the same. Match the number to the loss it bounds: RTO for time to restore service, RPO for the age of restored data, MTD for the ceiling both must fit inside.

The privacy scope trap. The scenario contains no unauthorized access, or mentions that the data is encrypted, and asks whether a privacy requirement is satisfied. Correct answers reach for purpose, minimization, lawful basis, and lifecycle coverage. Distractors equate privacy with confidentiality.

The scope-of-evidence item. An attestation, an ISO/IEC 27001 certificate, or a high EAL is offered as proof. Correct answers check scope, service, period, exclusions, and customer responsibilities before accepting the claim.

The legal-interpretation item. Two regulations appear to conflict, or a clause is ambiguous. The architect obtains the authoritative interpretation from legal counsel and then translates it into verifiable requirements, rather than resolving the law independently.

A reading strategy that works across all six: check which stage of the chain an option skips. Options that select a control before establishing authority, applicability, or scope are usually the distractors, and the answer that establishes the requirement before spending on a solution is usually the one the item wants.