NISP Level 2 common mistakes
NISP Level 2 · Understand the traps and how to avoid them.
When a scenario describes a control, treating any technical mechanism (firewall, encryption, IDS) as a 'technical control' even when the question is testing control categories by function, and picking 'technical' for things like security awareness training or policy enforcement performed by people.
Candidates memorize the technical/management/operational triad loosely and default to 'technical' whenever a tool is mentioned, without first asking whether the control's purpose is prevention, detection, correction, or deterrence and who or what executes it. The exam deliberately mixes the axis 'nature of control' (technical vs. management vs. operational) with 'function' (preventive, detective, corrective, deterrent, recovery, compensating).
What to do instead
Before answering, write two labels for the control: (1) function - does it stop, find, fix, scare, or restore? (2) nature - is it executed by a machine, by a document/decision, or by a daily human process? Only then map to the option. Practice by classifying 20 controls you know from real life into both axes until the two questions become automatic.
Selecting 'implement a firewall rule' or 'deploy an IDS' as the answer to a risk-treatment question where the stem says the organization has decided to accept, transfer, or avoid the risk, or where the residual risk is already within tolerance.
Candidates conflate risk treatment with 'add a control'. The exam often gives a scenario where the correct answer is a management action (document acceptance with sign-off, buy cyber insurance, exit the business line), and the technical option is a distractor because it does not match the chosen treatment strategy or ignores cost-benefit.
What to do instead
Read the stem for the decision already made or the constraint (budget, tolerance, contractual). Match the answer to the named treatment option: mitigate = reduce likelihood/impact; transfer = insurance/contract; avoid = stop the activity; accept = documented, authorized acceptance. Reject any option that adds cost without changing the stated risk position.
Confusing symmetric and asymmetric key usage in hybrid encryption scenarios - answering that the message body is encrypted with the recipient's public key, or that a digital signature is created by encrypting with the sender's public key.
The two operations (confidentiality vs. authentication) both involve public/private key pairs, and candidates memorize 'public encrypts, private decrypts' without attaching it to the correct goal. They also forget that in practice bulk data uses a symmetric session key wrapped by asymmetric crypto.
What to do instead
Anchor two one-line rules: confidentiality → encrypt with recipient's public key, decrypt with recipient's private key; authenticity/non-repudiation → sign with sender's private key, verify with sender's public key. For hybrid, state explicitly: random symmetric key encrypts the data, recipient's public key encrypts the symmetric key. Draw the four-key diagram from memory before the exam.
Answering 'hash the password with MD5/SHA-1' or 'encrypt the password so it can be decrypted for verification' when asked how to store credentials, instead of a salted, slow password-hashing function (bcrypt, scrypt, Argon2, PBKDF2).
Candidates know hashing is 'one-way' but do not distinguish fast general-purpose hashes from password-hashing KDFs, and they confuse encryption (reversible) with hashing. The exam tests whether you understand why speed and salt matter against offline cracking and rainbow tables.
What to do instead
Memorize the criteria: one-way, unique per-user salt, deliberately slow and memory-hard, tunable cost factor. Map MD5/SHA-1/SHA-256 to 'integrity, not password storage', and encryption to 'reversible, needs key management'. Be ready to explain what a salt defeats (precomputation/rainbow tables) versus what it does not (weak passwords).
Treating the OSI layer of a device or attack by the device name rather than by what the scenario describes - e.g., calling a switch a Layer 2 device when the question describes routing between VLANs, or labeling ARP spoofing as Layer 4 because it 'affects TCP'.
Candidates map devices and attacks to layers from memory of a table, but exam stems describe behaviour (broadcast domain, MAC-to-IP resolution, port numbers, HTTP headers) and expect you to derive the layer from the described function.
What to do instead
For every layer question, extract the concrete artifact in the stem: MAC address → Layer 2; IP address/routing → Layer 3; port number/TCP flags → Layer 4; protocol payload/HTTP/DNS query content → Layer 7. Build a personal cheat sheet of 15 attacks (ARP spoofing, VLAN hopping, SYN flood, DNS poisoning, SQLi) with the layer and the artifact that proves it.
Choosing 'block all inbound traffic' or 'disable the service' as the fix for a vulnerability when the scenario requires the service to remain available, instead of segmenting, applying least privilege, patching, or adding compensating controls.
Candidates reach for the most secure-sounding option and ignore the business/availability constraint stated in the stem. Security exams reward the control that reduces risk while preserving the stated requirement, not the most restrictive one.
What to do instead
Underline the constraint words in the stem ('must remain available', '24x7', 'legacy client'). Eliminate any option that violates a stated constraint before comparing the rest on risk reduction and cost. Prefer layered, targeted controls (patch, ACL, segmentation, monitoring) over wholesale shutdown.
Mixing up incident response phases - placing containment before identification, or calling eradication 'recovery', or treating lessons-learned as part of containment - when the question asks what the team should do next at a described point in the timeline.
Candidates remember the phase names but not their boundaries, and exam stems describe a moment in time ('the malware is still spreading', 'the server has been rebuilt') that uniquely determines the next phase.
What to do instead
Memorize the sequence with a trigger for each transition: Preparation → Detection & Analysis (confirm scope) → Containment (stop spread) → Eradication (remove root cause) → Recovery (restore to production, verify) → Lessons Learned (post-incident review). Practice by reading a timeline and naming the phase from the verb in the stem: 'still spreading' = contain; 'root cause removed' = recover; 'service restored and monitored' = lessons learned.
Confusing vulnerability assessment with penetration testing - answering 'run a pentest' when the question asks for broad, repeatable coverage of known weaknesses, or answering 'run a scanner' when the question asks to prove exploitability of a specific business-logic flaw.
Both are security assessment activities, and candidates treat them as synonyms. The exam tests scope, depth, authorization, and reporting differences: scanners find known signatures at scale; pentests chain vulnerabilities and test business logic under rules of engagement.
What to do instead
Hold two profiles in mind. Vulnerability assessment: broad, automated, credentialed scans, prioritized by CVSS plus context, recurring cycle, output is a list with remediation. Penetration test: scoped, manual, goal-oriented, rules of engagement and written authorization, output is an exploit narrative with business impact. Match the answer to the stated goal: coverage vs. proof.
Applying the wrong Chinese legal instrument to a scenario - citing the Cybersecurity Law (网络安全法) for personal-information processing obligations, or the Data Security Law (数据安全法) for cross-border transfer of personal information, when the Personal Information Protection Law (个人信息保护法) or the relevant regulation is the governing rule.
The three laws overlap and candidates learn them as a single block. Stems describe a specific obligation (consent, separate consent for sensitive data, data classification, critical information infrastructure, cross-border transfer) and expect the instrument that creates that obligation.
What to do instead
Build a one-page map: Cybersecurity Law → network operation security, CII protection, real-name and logging duties; Data Security Law → data classification/grading, important data, national data security; PIPL → personal information processing rules, consent, sensitive PI, individual rights, cross-border transfer of PI. For each practice question, identify the object (network, data, personal information) first, then pick the law.
Treating cloud shared-responsibility as 'the provider secures everything' or 'the customer secures everything', and misassigning a control (e.g., saying the provider is responsible for customer IAM configuration or for data classification) in IaaS, PaaS, and SaaS scenarios.
Candidates learn one slogan and apply it uniformly, but the boundary moves with the service model. The exam tests whether you can place a specific control on the correct side of the line for the stated model.
What to do instead
Use the rule 'provider secures the cloud, customer secures what they put in and configure in the cloud', then adjust per model: IaaS - customer owns OS, patching, IAM, data; PaaS - customer owns application code, configuration, data, provider owns runtime and below; SaaS - customer owns data, access management, and usage configuration. Practice by listing five controls and placing each for all three models.