ICSAN MIS common mistakes
ICSAN MIS · Understand the traps and how to avoid them.
Treating IT governance as an IT-department activity and attributing decisions about strategy, funding and risk appetite to the CIO alone, when questions ask who is accountable for governing information systems.
Candidates carry over the everyday assumption that technology matters are technical, so they pick the most technical-sounding role (CIO, IT manager, security officer) instead of the board or an accountable executive committee.
What to do instead
Before answering any governance question, separate three layers: the board sets direction and risk appetite, executive management (including the CIO) implements it, and IT delivers it. Map each option to a layer and reject options that place accountability for direction below board level. Learn the standard committee structure (board, audit committee, IT steering committee) and what each owns.
Confusing governance with management, and confusing frameworks with standards, so options such as 'the IT director approves the IT strategy' or 'COBIT is a control catalogue for auditors only' are selected.
The vocabulary overlaps heavily and revision notes often list framework names without their purpose, so candidates match on the familiar acronym rather than on the function described in the stem.
What to do instead
Build a one-line purpose card for each framework: COBIT (governance and management objectives), ITIL (service management practices), ISO/IEC 27001 (ISMS requirements), ISO/IEC 27002 (control guidance), COSO (enterprise risk and internal control), Val IT (investment value). Then practise classifying the verb in the stem: 'evaluates, directs, monitors' signals governance; 'plans, builds, runs' signals management.
Answering information security questions by choosing the strongest-sounding control (for example 'encrypt everything' or 'block all external access') rather than the control that addresses the specific risk, threat or asset named in the scenario.
Security questions are written as realistic scenarios and the plausible distractor is usually a valid control applied in the wrong place; candidates select on general good practice instead of tracing the risk path in the stem.
What to do instead
Use a fixed routine: identify the asset, the threat, the vulnerability and the impact stated, then ask which option breaks that specific chain. Practise distinguishing confidentiality, integrity and availability failures and matching controls to each. Where a question asks for the 'best' or 'most appropriate' control, eliminate options that are disproportionate, technically infeasible in the stated context, or that address a risk not mentioned.
Treating risk as a list of threats and ignoring likelihood, impact, risk appetite and treatment options, so answers recommend 'avoid the risk' or 'transfer it to the vendor' without checking whether the scenario supports that treatment.
Candidates memorise threat names but not the risk-management process, and they miss that acceptance, mitigation, transfer and avoidance each have preconditions such as cost, contractual terms or residual risk tolerance.
What to do instead
Learn the sequence identify, analyse, evaluate, treat, monitor and communicate, and apply it out loud to each scenario. For treatment questions, test the option against three filters: does it reduce likelihood or impact, is it within the organisation's stated appetite, and is it cost-effective relative to the asset value. Note that insurance transfers financial impact, not accountability.
Choosing a system development life cycle model by reputation rather than by fit, for example prescribing waterfall for a project with unstable requirements or agile for a fixed-price regulatory delivery with heavy documentation obligations.
Revision material presents models as a list to be recalled, and candidates associate agile with being modern and waterfall with being outdated, so they ignore the risk profile, requirement stability and contractual context in the stem.
What to do instead
Create a decision table matching model to conditions: requirement volatility, delivery cadence, regulatory documentation, team co-location, contract type. Practise writing one sentence justifying the choice from facts in the stem. Also learn the hybrid answer pattern, where an iterative delivery is wrapped in stage-gate governance for approval and audit purposes.
Confusing project management roles and artefacts, such as attributing ownership of the business case to the project manager, treating the project sponsor as the person who does the scheduling, or mixing up a risk register with an issue log.
The roles sound hierarchical and candidates map them onto seniority rather than onto accountability; artefacts are memorised as names without their purpose or owner.
What to do instead
Learn each artefact by the question it answers: business case (should we invest and is benefit still justified), charter (what is authorised and who is accountable), risk register (what might happen), issue log (what has happened and needs resolution), change request (what is being altered in scope, time or cost). Attach an owner to each and remember that the sponsor owns the business case and benefits, while the project manager owns delivery.
Mixing up ERP, CRM and SCM scope, or describing ERP as software installation rather than as integrated process and data standardisation, leading to wrong answers on implementation critical success factors.
Vendor marketing language blurs the boundaries, and candidates learn product names instead of the business processes each class of system integrates.
What to do instead
Anchor each system to the process it integrates: ERP to finance, procurement, manufacturing and HR in one shared data model; CRM to the customer lifecycle from lead to service; SCM to planning, sourcing, logistics and supplier collaboration. For implementation questions, prioritise executive sponsorship, process ownership, data cleansing and change management over technical configuration, because those are the factors that determine failure in practice.
Confusing data management concepts, for example treating a data warehouse as a copy of the operational database, equating data governance with database administration, or describing normalisation as a performance-tuning technique.
The terms are learned as definitions in isolation, so candidates cannot apply them to a scenario about reporting quality, master data duplication or extract-transform-load design.
What to do instead
Learn the layers as a chain: source systems, ETL, warehouse or lake, semantic layer, reporting and analytics, with master data management providing consistent reference data across sources. For each concept, write the problem it solves (warehouse: integrated historical analysis without loading operational systems; normalisation: removing redundancy and update anomalies; governance: accountability for data quality and definition).
Answering service management questions by instinct rather than by process, for example escalating an incident as a problem, treating a change as a release, or promising a fix time that the service level agreement does not cover.
The processes overlap in daily practice and the distinctions look academic, so candidates answer from workplace habit rather than from the framework's definitions.
What to do instead
Memorise the distinctions as purpose statements: incident restores service quickly, problem removes the root cause, change controls risk of modification, release deploys a tested version, service level agreement defines commitments, operational level agreement supports it internally. Practise classifying short scenario stems into one of these before looking at the options.
Ignoring legal, regulatory and ethical dimensions and choosing the technically efficient answer, for example transferring personal data offshore because the vendor offers it, or monitoring employees because the tooling exists.
Candidates from a technical background treat compliance as a constraint added at the end, and data protection principles are remembered as slogans rather than as tests applied to a scenario.
What to do instead
For any scenario involving personal data, run a fixed check: lawful basis, purpose limitation, minimisation, retention, cross-border transfer safeguards, and the data subject's rights. For professional ethics, apply the public-interest test and disclose conflicts rather than resolving them quietly. Learn the local regulator and statute names for your jurisdiction so you can recognise the correct option without guessing.