BCS CISMP common mistakes
BCS CISMP · Understand the traps and how to avoid them.
When asked who is accountable for an information asset, candidates name the IT team, the security officer, or the system administrator rather than the business owner who relies on the asset.
Technical training encourages people to equate information security with technical operations, so the nearest technical role is chosen by default. The distinction between accountable (senior business owner) and responsible (person who carries out the work) is blurred, and governance language in the question goes unnoticed.
What to do instead
Before answering any ownership question, separate the two roles explicitly: accountability sits with the senior manager who owns the business process and accepts the residual risk; responsibility for day-to-day operation can be delegated. Practise classifying roles such as data owner, data custodian, system administrator and information security manager against those two definitions until the mapping is automatic.
Candidates treat risk assessment as a purely technical exercise, scoring likelihood and impact from the attacker's perspective and ignoring business impact, legal exposure and reputational harm.
Many candidates come from a technical background where vulnerability severity is the natural measure of seriousness. Business impact analysis feels like a separate discipline, so the business context in the scenario is skimmed rather than used.
What to do instead
For every risk question, restate the asset, the threat and the business consequence before scoring. Build a mental checklist of impact categories: financial, legal and regulatory, operational, safety, and reputational. When a scenario gives business details, use them as the impact evidence rather than inventing technical severity.
Candidates answer risk-treatment questions by choosing a control immediately, skipping the earlier steps of identifying options and comparing them against the organisation's risk appetite.
Control selection is the most familiar and concrete part of security work, so it feels like the productive answer. The exam often tests the process sequence and the concept of risk appetite, which candidates under-rehearse.
What to do instead
Learn the treatment options as a set: avoid, reduce or mitigate, transfer or share, and accept. For each practice question, first state the risk appetite position implied by the scenario, then eliminate options that breach it, then select the control. Write one sentence justifying why the rejected options fail before committing to an answer.
Candidates describe a standard or framework as a mandatory legal requirement, or claim certification to a standard guarantees legal compliance.
Standards, frameworks, regulations and laws are often discussed together in study material, and the words are used loosely in everyday speech. Candidates memorise names without attaching the correct status to each one.
What to do instead
Keep a three-column table: law or regulation (mandatory, enforced by a regulator), standard (voluntary unless contractually or regulatorily imposed), and framework or good-practice guidance (advisory). For each named instrument in the syllabus, record its issuing body, its status and one example of how it becomes binding, for example through contract or sector regulation.
Candidates confuse the Plan-Do-Check-Act cycle with the ISO/IEC 27001 certification process, describing certification as an ongoing internal activity rather than periodic independent audit.
Both involve staged, cyclical activity, and revision material often presents them side by side. The roles of internal audit, management review and external certification bodies are not clearly separated in candidates' minds.
What to do instead
Draw the cycle once and label each phase with concrete artefacts: scope and risk assessment in Plan, implement and operate in Do, internal audit and management review in Check, corrective action in Act. Separately note that certification is granted by an accredited external body after a stage-one and stage-two audit and maintained through surveillance audits.
Candidates select the strongest available control for a scenario instead of the control proportionate to the identified risk and the organisation's constraints.
Security instinct favours maximum protection, and exam options often include a very strong control that is technically valid but commercially or operationally disproportionate. Candidates overlook cost, usability and residual risk.
What to do instead
Apply a proportionality test to each candidate control: does it address the specific threat, is the cost justified by the reduction in risk, and does it fit the organisation's culture and legal context? Eliminate any option that is technically sound but disproportionate, then choose among the remaining proportionate options.
Candidates treat defence in depth as a list of products to buy, naming several tools without explaining how the layers compensate for one another when a single control fails.
Vendor terminology and product familiarity dominate candidates' vocabulary, and layered architecture is understood as quantity rather than as designed redundancy.
What to do instead
Practise explaining defence in depth using a single asset, such as a customer database, and describe preventive, detective and corrective layers around it: access control, encryption, logging and monitoring, backup and recovery. State explicitly what happens when each layer fails and which other layer then limits the damage.
Candidates describe incident response as starting with eradication or recovery, omitting preparation, identification and containment, and failing to distinguish an event from an incident.
In real workplaces people often first hear about a problem when it is already being fixed, so the early phases are invisible. The vocabulary of events, alerts and incidents is used interchangeably.
What to do instead
Memorise the response lifecycle as an ordered sequence: prepare, identify, contain, eradicate, recover, and learn lessons. For scenario questions, locate the described situation in that sequence before reading the options, and reject any option that jumps ahead of the current phase. Keep a one-line definition of event, incident and breach.
Candidates confuse business continuity with disaster recovery, treating recovery of IT systems as the whole continuity objective and ignoring critical business processes and their maximum tolerable outage.
IT professionals naturally see system restoration as the core of resilience, and the two disciplines overlap heavily in practice. Recovery time and recovery point objectives are memorised without being tied to business processes.
What to do instead
Anchor continuity in the business impact analysis: identify critical processes, their maximum tolerable period of disruption, and the resources they need. Then place disaster recovery underneath as the IT-focused subset that restores technology within the recovery time objective. For each scenario, ask which business process is at risk before discussing systems.
Candidates answer legal, regulatory and contractual questions from general principle rather than identifying the specific jurisdiction, sector regulator or contractual clause named in the scenario.
Candidates rely on broad impressions of what is 'required' and do not systematically extract the governing context from the question stem. Cross-border data transfer and sector-specific rules are especially prone to guesswork.
What to do instead
Adopt a fixed reading routine: underline the organisation's sector, location, data types and any named contract or regulator before evaluating options. Build a short reference list linking each major regime in the syllabus to its scope and one distinctive obligation, and practise rejecting options that apply the wrong regime to the scenario.