ISSAP common mistakes
ISSAP · Understand the traps and how to avoid them.
Answering GRC scenario questions with a control implementation (e.g., 'deploy DLP') instead of stating the governance artifact - policy, standard, risk appetite statement, or exception process - that authorizes and bounds the control.
Candidates carry over a hands-on security-engineering reflex from operational exams; ISSAP scenarios are written at the architect/governance layer, and the 'best' option is usually the one that establishes authority, accountability, and traceability rather than the one that is most technical.
What to do instead
Before choosing, ask 'who decides, who is accountable, and what document records it?' If the stem involves executives, regulators, or business units, prefer the answer that creates or applies a governance mechanism (policy hierarchy, risk register entry, RACI, exception with sign-off). Reserve technical controls for stems explicitly about design or implementation.
Treating compliance as equivalent to security and selecting 'achieve certification' or 'pass the audit' as the objective, rather than distinguishing the compliance obligation from the residual risk decision.
Frameworks and regulations are memorizable, so candidates anchor on the framework name in the stem and pick the answer that satisfies the auditor; the exam instead tests whether the architect can hold compliance and risk as separate concerns and document accepted residual risk.
What to do instead
Map each option to either 'satisfies an external obligation' or 'reduces/manages risk.' When a stem shows a gap that a framework does not cover, the correct answer is usually to record and treat the risk (risk treatment plan, management acceptance) while meeting the compliance minimum separately - not to declare the control sufficient because the audit passed.
Jumping straight to a solution architecture in 'identify security architecture approach' items without first eliciting and prioritizing business, legal, regulatory, and organizational drivers and deriving security requirements from them.
Experienced architects have a preferred reference architecture and pattern library; under time pressure they pattern-match the scenario to a familiar design and skip the requirements-derivation step the question is actually testing.
What to do instead
For any approach-selection stem, mentally run driver → requirement → constraint → architecture. Eliminate options that prescribe technology before requirements are established, and prefer answers that show traceability from a named driver (contractual, statutory, mission) to a security requirement and then to an architectural decision.
Confusing legal/regulatory applicability - e.g., assuming a regulation applies because data is stored in a jurisdiction, or ignoring cross-border transfer, data residency, and sector-specific obligations - and choosing an answer that misstates which requirement binds the organization.
Candidates memorize regulation names and headline requirements but not triggers and scope (who is a controller vs processor, what counts as personal data, when a transfer occurs), so they apply the wrong regime to the scenario.
What to do instead
For each legal stem, explicitly identify: the data category, the jurisdictions involved, the organization's role, and the triggering event. Eliminate options that apply a regime without a trigger or that ignore contractual flow-down obligations. Where two regimes overlap, prefer the answer that satisfies the strictest applicable requirement and documents the mapping.
Skipping verification and validation as a distinct lifecycle activity - accepting a design because it looks sound or because a vendor claims certification, instead of requiring traceable validation against requirements and independent verification evidence.
Design work feels complete once documented; candidates underweight the exam's insistence that architecture must be proven against requirements through review, testing, modeling, or independent assessment, and they conflate 'validated by vendor' with 'validated for our requirements'.
What to do instead
When a stem asks how to confirm a design meets its objectives, choose the option that ties evidence back to specific requirements (requirements traceability matrix, threat model review, control testing, independent assessor). Reject options that substitute reputation, certification, or self-attestation for requirement-specific evidence.
Accepting a design review sign-off as proof of security, without checking that the validation method matches the risk (e.g., tabletop review for a high-impact trust boundary, or no negative/adversarial testing of the architecture's assumptions).
Candidates default to the lightest-weight assurance activity because it is familiar and fast, and they do not scale assurance rigor to impact, so they pick documentation reviews for scenarios that demand adversarial or independent validation.
What to do instead
Calibrate: the higher the impact and the more novel the design, the more adversarial and independent the validation. Prefer answers that select validation depth proportional to risk, include abuse-case/threat-driven testing, and feed findings back into the design rather than closing them as documentation defects.
Designing infrastructure security as a flat set of point controls (a firewall here, encryption there) rather than as layered, defense-in-depth segmentation with clearly defined trust boundaries and a documented failure/containment model.
Operational habits produce control checklists; ISSAP infrastructure stems reward architects who reason about zones, choke points, least privilege between tiers, and what happens when a layer fails.
What to do instead
For infrastructure stems, first draw the trust boundaries and data flows, then place controls at choke points, and ask what a compromise of each zone yields. Choose options that reduce blast radius (segmentation, least-privilege service identities, egress control) and that specify monitoring at boundaries over options that merely add an isolated control.
Stating infrastructure and system security requirements qualitatively ('must be secure', 'high availability') instead of as verifiable, testable, prioritized requirements with measurable acceptance criteria and explicit assumptions.
Stakeholders speak in outcomes and candidates transcribe them verbatim; the exam tests whether the architect can convert business intent into requirements an engineer can build to and an assessor can test.
What to do instead
Rewrite each requirement with a subject, behavior, condition, and measurable threshold (e.g., session termination, recovery time, key rotation interval), tag it to its driver, and mark priority (mandatory vs. desirable). Eliminate options containing unmeasurable adjectives when a measurable alternative is offered.
Treating identity as a provisioning task and ignoring the full lifecycle - authoritative source, joiner/mover/leaver, entitlement review, orphaned and dormant account handling, and deprovisioning SLAs - so lifecycle gaps go undetected in scenario answers.
Candidates focus on authentication mechanics (MFA, federation) because those are technically rich, and they underweight the governance of identity state over time, which is where most real breaches and most exam items live.
What to do instead
For identity stems, trace an identity from authoritative source through creation, role/entitlement change, periodic recertification, and termination, and check each transition has an owner and a control. Prefer answers that fix the lifecycle process (automated deprovisioning tied to HR events, access reviews, orphan detection) over answers that add another authentication factor.
Choosing an authorization model by familiarity (RBAC everywhere) without matching it to the scenario's granularity, dynamism, and regulatory needs - e.g., ignoring ABAC/PBAC for context-sensitive access, or omitting accounting/audit logging and non-repudiation from the design.
RBAC is the default mental model, and accounting (logging, monitoring, audit trail integrity) is treated as an operations afterthought rather than an architectural requirement, so candidates pick plausible but mismatched authorization designs and under-specify auditability.
What to do instead
Match the model to the decision inputs: static job function → RBAC; attributes/context (time, location, data sensitivity, risk score) → ABAC/PBAC; delegated or cross-organization access → federation with scoped claims. Always confirm the chosen model produces attributable, tamper-evident accounting records sufficient for the stated regulatory or forensic need, and prefer options that specify both the decision model and the audit evidence it generates.