EXIN ISFS common mistakes
EXIN ISFS · Understand the traps and how to avoid them.
Treating confidentiality, integrity and availability as three separate topics and answering a scenario question by naming only the one that is most obvious, for example calling a defaced public website only an integrity issue.
Candidates memorise the three letters as a list and never practise applying all three to one event, so they stop at the first plausible label and miss the secondary loss of availability or trust.
What to do instead
For every scenario, run all three criteria explicitly before choosing: who should not see it (confidentiality), is it still correct and complete (integrity), can the right people still use it when needed (availability). Write the three words on your scratch paper and tick or cross each one.
Confusing a threat, a vulnerability and a risk, for example calling an unpatched server the threat or calling a burglar the risk.
The words are used loosely in everyday speech, and exam items deliberately place a concrete actor, a weakness and a combined likelihood-impact statement in the same question stem.
What to do instead
Apply fixed definitions: a threat is anything that could cause harm (a person, a group, an event); a vulnerability is a weakness that a threat could exploit (missing patch, poor procedure); risk is the combination of the chance of the event and its impact. Test yourself by labelling the same scenario three ways until the categories stop blurring.
Mixing up preventive, detective and corrective measures, for example classifying a backup restore as preventive or an access log as corrective.
Candidates classify by how technical or expensive the control feels rather than by when it acts relative to the incident, so a firewall and a backup feel equally 'security' and get the same label.
What to do instead
Ask one question: does it act before, during or after the incident? Before is preventive (access control, encryption, policy), during or just after detection is detective (logging, monitoring, alarm, audit trail), after is corrective (restore, patch, disciplinary action, business continuity). Sort a list of twenty familiar controls into the three buckets from memory.
Answering a question about the role of an employee, a manager or the security officer by giving the technically ideal answer rather than the responsibility the standard actually assigns.
Candidates reason from what would be best practice in their own organisation instead of from the division of duties described in the syllabus, where the line manager owns risk acceptance in their area and the security officer advises and monitors.
What to do instead
Learn the responsibility split as roles, not tasks: senior management sets direction and accepts residual risk, line managers implement and own controls in their process, every employee follows policy and reports incidents, the security officer coordinates and advises but does not own every risk. When a stem names a role, ask what that role is accountable for, not what would fix the problem fastest.
Confusing an incident with a weakness found during a test, and therefore reporting every finding as a security incident.
Both feel like 'something is wrong with security', and candidates have not internalised that an incident is an actual unwanted event that has occurred or is occurring, while a finding is a potential exposure.
What to do instead
Use the test 'has it happened?'. A lost laptop, a malware infection or a defaced page has happened and is an incident; a missing patch, a weak password rule or an unlocked cabinet is a weakness or nonconformity to be fixed through normal management. Practise sorting ten short statements into incident, weakness and neither.
Treating ISO/IEC 27001 as a list of security controls to be implemented in full, rather than as a management system standard in which controls are selected through risk assessment.
The standard's Annex A control catalogue is the most concrete and memorable part, so candidates reduce the whole standard to 'implement all the controls' and miss the plan-do-check-act logic that most questions test.
What to do instead
State the standard's logic in one sentence before answering: establish the management system, assess risk, select and implement controls to treat that risk, check performance, improve. Then check whether the question asks about the management system (policy, roles, audit, review) or about a control; answer in that register.
Believing a Statement of Applicability must include every Annex A control as applicable, and marking controls as applicable simply because they sound useful.
Candidates think a complete document must list everything as in scope, and they do not connect the Statement of Applicability to the risk treatment decisions that justify each entry.
What to do instead
Remember that the Statement of Applicability records which controls are applicable and why, and that a control can legitimately be excluded with a documented justification. For each entry ask: which risk treatment decision or legal or contractual requirement puts this control in scope? If you cannot name one, it is a candidate for exclusion with justification.
Treating risk assessment and risk treatment as the same step, or forgetting that risk treatment options include accepting, avoiding and transferring risk, not only applying controls.
In practice many organisations jump straight to 'what control do we buy', so candidates equate treatment with mitigation and overlook acceptance, avoidance and transfer in scenario questions.
What to do instead
Keep the sequence explicit: identify assets and owners, assess likelihood and impact, compare with the risk criteria, then choose a treatment option (modify, avoid, transfer, accept) and record residual risk with the owner's approval. When a stem describes a decision not to act, recognise it as acceptance and check whether it was authorised by the right level.
Confusing the Plan-Do-Check-Act stages with the documentation hierarchy, for example placing internal audit under Do or management review under Act without linking them to the check and improve logic.
Both are ordered frameworks, so candidates map them by position in a list rather than by function, and audit and management review feel like administrative activities rather than verification steps.
What to do instead
Anchor each stage to its purpose: Plan sets policy, scope and risk treatment; Do implements and operates; Check monitors, measures, audits and reviews; Act corrects and improves. Place internal audit and management review firmly in Check because they verify, and corrective action in Act because it changes the system.
Answering questions about the standard's requirements with what a good organisation would do beyond the requirement, such as insisting on certification for every supplier or on annual penetration testing for all systems.
Candidates bring real-world habits and vendor advice into an exam that tests the requirement itself, and the more demanding answer sounds more secure.
What to do instead
For each requirement, separate 'shall' from 'should'. Ask what the standard actually requires the organisation to do (for example, define security requirements for suppliers and monitor their performance) versus what a particular organisation might choose. Choose the answer that matches the requirement, and treat extra rigour as a context-specific decision, not a universal rule.