CISSP - Security Architecture and Engineering (13% of the exam) - Section 3.3

Select controls based upon systems security requirements.

Use Common Criteria evaluation assurance levels (EALs) and formal security requirements to guide control selection for a target system. Weigh the assurance level needed against cost and operational constraints so that selected controls are proportionate to the system's risk profile.

Common Criteriasecurity requirementscontrol selectionassurance levels

Practice question for this objective

Free sampleSecurity Architecture and Engineeringmedium

A regional bank is procuring a new hardware security module to protect customer signing keys for an internet banking platform. The procurement team has shortlisted two vendors that both advertise FIPS 140-3 Level 3 validation, but one product also carries a Common Criteria EAL4+ certification against a published protection profile and the other carries no Common Criteria evaluation. The CISO must justify the selection to the board on a security-requirements basis. What should be the PRIMARY driver of the control selection decision?

AMap the bank's documented signing-key protection requirements to the security functional requirements in the protection profile that each product was evaluated against, and select the product whose evaluated scope matches. Correct
BChoose the EAL4+ product because a higher assurance label generally indicates a more secure device against modern threats.
CChoose whichever product has the longer FIPS 140-3 validation certificate history, since regulators tend to favour mature cryptographic modules.
DDefer the decision to the vendor risk team and pick the product with the better contractual indemnity for cryptographic key compromise.

Select security controls by mapping documented requirements to the evaluated security functions in the relevant Common Criteria protection profile. Common Criteria evaluations only assert assurance against the security functions inside a chosen protection profile or security target. A higher EAL number means deeper evaluation, not broader functionality, so a requirements-led selection asks whether the evaluated functions actually cover the organisation's stated security requirements before weighing assurance depth or commercial factors.

Why A is correct: Control selection under a requirements-led approach starts from the organisation's security requirements, then chooses a control whose evaluated security functions cover those requirements, which is exactly how Common Criteria protection profiles are intended to be used in procurement.

Why B is wrong: Tempting because candidates often equate higher EAL numbers with better security, but Common Criteria assurance levels describe the rigour of evaluation against a specific protection profile, not absolute security strength, so picking on label alone ignores whether the evaluated functionality actually matches the bank's signing-key threat model.

Why C is wrong: Plausible because regulators do scrutinise cryptographic module validation, yet validation age is a weak proxy for fit, and ignoring the protection profile means the bank cannot demonstrate that the evaluated functions cover its actual signing-key requirements.

Why D is wrong: Indemnity matters for residual risk transfer, but it is a commercial control rather than a technical control, and selecting a security control primarily on contractual recourse rather than evaluated security functionality inverts the requirements-driven model the CISSP expects.

See more CISSP practice questions, answers explained.

Exam traps in Security Architecture and Engineering

Answers that look right on this material and are not. Each one is a distractor from a different question in the CISSP bank for this domain.

Adopt the highest control baseline from a recognised catalogue so that the platform is covered against the widest range of threats from day one.
Why it is wrong: Picking the most stringent baseline feels safe and is a common candidate trap, but selecting controls before categorising the system leads to over-control in low-impact areas and gaps where the baseline did not anticipate the specific data, and it cannot be defended as risk-based.
Whether the two medium-severity findings have compensating controls documented in the change record before the cutover window opens.
Why it is wrong: Compensating controls are useful evidence, but their presence alone does not establish that residual risk is acceptable to the business. A control can be documented and still leave the system outside risk appetite, or be unnecessary if the underlying risk is already tolerated.
Approve the change conditionally on a follow-up penetration test before the next release, so the sprint velocity is not disrupted.
Why it is wrong: Deferring assessment to a penetration test treats a scope change as a testing problem. Penetration testing verifies implementation against requirements; if the requirements themselves have shifted, the test has no benchmark to assess against and the risk decision is postponed rather than resolved.

Examworthy is not affiliated with or endorsed by ISC2. Original, blueprint-aligned practice material only.