UnixTime

Research Note

Common Exam Traps

  • Updated Jun 17, 2026
  • Read 28 mins read
  • Status reviewed

Research note.

On this page

Clauses 4-10 vs Annex A

Trap Correction
Clauses 4-10 can be excluded if not relevant They cannot be excluded
All Annex A controls are mandatory Annex A controls are selected based on risk and justified in the SoA
ISO 27002 is used for certification ISO 27001 is certifiable; ISO 27002 is guidance
No third-party audit means no internal audit Internal audit is mandatory for ISO 27001 conformity

Control attributes

Trap Correction
Attributes are mandatory requirements Attributes are optional metadata
Attributes replace risk assessment They support analysis but do not replace risk assessment
Attributes replace the SoA They do not replace applicability justification
The main purpose is cost reduction Main purpose is categorization, analysis, selection, review, and mapping

A.5.1 Policies

Trap Correction
Having a policy document is enough It must be approved, published, communicated, acknowledged, controlled, and reviewed
Top-level policy should contain every detail It should be concise and link to topic-specific policies
Only employees need access to policy requirements Relevant external parties may also need them
Review only happens annually Review should be planned and triggered by significant changes

A.5.2 Roles and responsibilities

Trap Correction
Only security team needs defined responsibilities Everyone needs baseline responsibilities; special roles need specific ones
Appointing a CISO satisfies the control Not enough; responsibilities must be allocated across the organization
Delegation transfers accountability Accountability remains unless formally reassigned
Contractors are exceptions Contractors and third parties must be covered
“Everyone is responsible” is enough Too vague; specific accountability is needed

A.5.3 Segregation of duties

Trap Correction
SoD applies only to finance It applies to information security, access, change, audit, logs, suppliers, etc.
Small organizations can ignore SoD They need compensating controls where full segregation is impractical
Logging alone is enough Logs must be tamper-resistant and independently reviewed
Two people automatically means segregation Independence and role separation must be effective
SoD eliminates collusion It reduces risk but does not eliminate it

A.5.4 Management responsibilities

Trap Correction
Management responsibility means only top management Line managers and department heads are included
Security team enforces everything Managers must require personnel to follow policies and procedures
Policy approval proves management responsibility Not enough; managers must reinforce security in daily work
Awareness training alone is enough Managers must verify compliance and address non-compliance
Senior people can have informal exceptions Exceptions should be risk-assessed, approved, documented, and reviewed

A.5.5 Contact with authorities

Trap Correction
Authorities means only police It can include regulators, CERTs, emergency services, sector bodies, and other official authorities
A contact list is enough Purpose, trigger, owner, authorization, review, and disclosure rules are also needed
Contact is only needed after incidents Some relationships are time-driven or preparedness-driven
Contacting authorities means sharing everything External disclosure still needs approval and confidentiality handling

A.5.6 Contact with special interest groups

Trap Correction
Only paid memberships count Free advisories, forums, briefings, and professional communities can be suitable
Small organizations can ignore this They need proportionate external awareness
Attendance alone is strong evidence Information should be shared internally or used
Professional networking permits disclosure Confidential information must still be protected

A.5.7 Threat intelligence

Trap Correction
Threat feeds equal threat intelligence Intelligence requires analysis, context, and use
Paid intelligence service satisfies the control by itself The organization still has to analyze and apply it
Internal incident history is enough External threat information is needed for emerging risks
Threat intelligence is only technical It can support management, risk, supplier, incident, and control decisions
AI/search can be used freely for research Sensitive organizational information can leak and must be controlled

A.5.8 Information security in project management

Trap Correction
Applies only to software development Applies to projects that affect systems, services, processes, suppliers, infrastructure, or data flows
Project risk register is enough Information security risk should be distinct and linked to ISMS risk management
Security can wait until go-live Security requirements should be identified early
Commercial software is automatically safe COTS, add-ons, integrations, and customizations still need security assessment
Functional testing is enough Security requirements must also be validated
Project team can remove controls to hit deadlines Security control removal needs proper risk escalation and acceptance

A.5.9 Inventory of information and other associated assets

Trap Correction
Asset inventory means hardware inventory It includes information and associated assets, including software, services, documents, media, and processes
IT is automatically the owner of all assets Business owners are accountable for value, classification, and protection expectations
Custodian equals owner Custodians operate or protect assets day to day; owners remain accountable
Inventory only needs to be created once It must be maintained through project, change, procurement, and disposal processes
Retained records that create liability are not assets They still require inventory, protection, retention, and disposal controls
Disposal can be handled informally Disposal should be recorded, authorized, and reflected in the inventory

A.5.10 Acceptable use of information and other associated assets

Trap Correction
Acceptable use only means internet browsing It covers information and associated assets in multiple forms
Device rules are enough Handling rules for information are also required
Classification labels are enough Users need practical handling procedures for each label
Employees are the only users in scope Contractors and third-party users may also need to accept the rules
A signed acknowledgement proves the control works Awareness, implementation, monitoring, and enforcement still matter

A.5.11 Return of assets

Trap Correction
Return of assets means only laptops It includes devices, cards, keys, documents, media, software, and information
Only termination triggers return Role changes and contract/agreement changes can also trigger return
Access removal is the same as asset return Related, but different controls
Contractors are out of scope Contractors and third-party users can be in scope
Personal-device data is irrelevant Organizational information on personal or third-party equipment must be returned or securely erased where applicable

A.5.12 Classification of information

Trap Correction
ISO defines universal classification labels Organizations define labels that fit their context
Classification only considers confidentiality Integrity, availability, and interested-party requirements also matter
Labels are enough Handling rules must explain what each classification requires
More classification levels are always better Too many levels cause inconsistent use
IT should classify everything Asset owners should classify or approve classification

A.5.13 Labelling of information

Trap Correction
Labelling is the same as classification Labelling makes classification visible or actionable
Only paper documents need labels Digital documents, email, repositories, systems, and media may also need labelling
Labels only matter at creation Labels should remain with information when form changes where practical
Most sensitive content can be ignored in a container The label should reflect the most sensitive information where practical
Visible labels are always best For highly sensitive material, controlled or disguised labelling may be justified

A.5.14 Information transfer

Trap Correction
Information transfer means email only It covers all transfer facilities, including messaging, file sharing, phone, fax, courier, print, removable media, and system integrations
Internal transfer does not need rules Internal and external transfers are both in scope
Disclaimers protect email transfers Disclaimers do not replace transfer controls
Classification is unrelated to transfer Classification should drive approved transfer methods and controls
Third-party transfers can rely on trust Agreements should define required transfer controls
Approved messaging platforms need no control Access, use cases, monitoring, and data types still need limits

A.5.15 Access control

Trap Correction
Access control is only logical/system access It covers physical and logical access
Senior roles automatically need broad access Access still needs business justification
Role-based access solves everything Role profiles must be designed and reviewed
Access review means checking users still exist Review must check whether access is still needed
Least privilege is optional Unnecessary access should be denied

A.5.16 Identity management

Trap Correction
Identity management means account creation It covers the full lifecycle
Shared accounts are acceptable if convenient Shared identities need justification and compensating accountability controls
User means only ordinary employees It includes administrators, support, developers, contractors, third-party users, and other users
Old identities can be reused Redundant identities should not be reissued
Identity and access are the same Identity identifies the user; access defines what the user can use

A.5.17 Authentication information

Trap Correction
User IDs and email addresses are secret authentication information They are identifiers, not secret authentication information
Authentication information means only passwords It can include PINs, recovery answers, biometric data/templates, tokens, and secrets
Identity management and authentication information are the same Identity identifies the user; authentication information helps prove the identity
Temporary/default credentials are harmless They must be controlled and changed
Password testing can be done casually Testing needs proper management authorization

A.5.18 Access rights

Trap Correction
Defining access rules is enough Rights must be provisioned, reviewed, modified, and removed
Leavers are the only problem Movers and long-tenured/promoted staff often retain old access
Access review means checking active users Review must compare actual access to authorized business need
Physical access is separate Physical access rights are in scope
Shared credentials can stay unchanged Change shared credentials when a user no longer needs access

A.5.19 Information security in supplier relationships

Trap Correction
Supplier security only matters when suppliers have system access Physical access, data exposure, products, services, and decision-support information also create risk
Procurement vendor list is enough Security exposure, owner, tiering, agreements, and review matter
Same questionnaire for every supplier is enough Controls should be proportional to risk and exposure
Subcontractors are the supplier’s problem only Delegated activities should be controlled contractually
Trust replaces contract controls Supplier requirements should be defined and enforceable

A.5.20 Addressing information security within supplier agreements

Trap Correction
Any signed supplier contract satisfies the control The agreement must include relevant information security requirements
Security requirements can be agreed after onboarding Required controls should be agreed before access or information sharing
Same security clause fits all suppliers Requirements should reflect supplier relationship, exposure, and risk
Supplier certification replaces contract terms Certification can support assurance, but relationship-specific requirements still matter
Operational staff can waive supplier requirements informally Deviations should be justified, risk-assessed, approved, and documented

A.5.21 Managing information security in the ICT supply chain

Trap Correction
ICT supply-chain risk means only the direct vendor Indirect suppliers, subcontractors, hosting, support, and components can create risk
General supplier management fully covers A.5.21 A.5.21 is specifically about ICT product and service supply chains
The organization must contract directly with every indirect supplier Risk is often managed through the direct supplier agreement and flow-down obligations
Low-risk and critical ICT suppliers need the same review depth Review depth should be proportionate to criticality and exposure
Supplier changes are operational only Changes in hosting, support, subcontractors, or data location can change security risk

A.5.22 Monitoring, review and change management of supplier services

Trap Correction
Supplier due diligence ends after contract signing Supplier services and security practices need ongoing monitoring and review
Receiving reports is enough Reports should be reviewed, evaluated, and acted on
SLA monitoring is the same as security monitoring Security practices, incidents, changes, and controls also matter
Supplier incidents stay with the supplier Supplier incidents may need to trigger the organization’s incident process
Supplier change acceptance is just procurement Material changes should trigger risk review and management approval where relevant

A.5.23 Information security for use of cloud services

Trap Correction
Cloud is just another supplier with no special treatment Cloud has specific shared responsibility, data location, support access, configuration, and exit risks
Provider certification proves the cloud service is secure Certification does not prove the customer’s configuration and responsibilities are handled
Data location is only a technical architecture detail Location affects legal, regulatory, contractual, and risk decisions
Cloud exit can be planned later Exit strategy is part of cloud governance from acquisition
Standard provider terms are automatically unacceptable Standard terms may be accepted if risks above tolerance are understood and approved

A.5.24 Information security incident management planning and preparation

Trap Correction
Incident management starts when an incident occurs The control is about planning and preparation before incidents happen
Incident management is only for cyberattacks Incidents can include failures, data loss, misdirected emails, physical events, and failed controls
A documented plan is enough Processes, roles, responsibilities, and reporting routes must be established and communicated
Every event needs the same escalation Triage and classification should guide escalation and response
Lessons learned are optional Incidents should feed corrective action, risk review, and ISMS improvement

A.5.25 Assessment and decision on information security events

Trap Correction
Every event is automatically an incident Events must be assessed and categorized using defined criteria
The first reporter decides final classification A point of contact may triage, but the incident team or authorized role may confirm classification
Verbal triage is enough The decision and supporting justification should be recorded
Classification is purely technical Legal, contractual, customer, and notification timelines can affect urgency
Categories never need review Categories should be reviewed for clarity, relevance, and usefulness

A.5.26 Response to information security incidents

Trap Correction
A good technical fix proves good incident response Response should follow documented procedures and leave records
Evidence can be considered after recovery Evidence needs should be decided early because response actions can alter evidence
Incident response is only an IT task Responsibilities can include business, legal, privacy, communications, suppliers, and management
Chat history is enough evidence Incident records should show decisions, actions, timing, owners, and follow-up
Procedures can stay generic Procedures should identify relevant activities and responsibilities

A.5.27 Learning from information security incidents

Trap Correction
Closing the incident is enough Knowledge from incidents should strengthen and improve controls
No incidents means the control is working It may mean reporting is weak or evidence is not being captured
Lessons learned means a meeting happened Learning should produce tracked improvements where needed
Human error is a complete root cause The review should examine controls, procedures, training, detection, response, and evidence handling
Lessons are only for security teams Anonymized case studies can improve wider awareness and training

A.5.28 Collection of evidence

Trap Correction
Evidence means screenshots attached to a ticket Evidence should be identified, collected, acquired, preserved, and protected
Chain of custody is only for police cases Chain of custody supports integrity and accountability whenever evidence may matter
Investigation can happen on original evidence Forensic work should use sound copies where originals may be needed later
Evidence collection can wait until legal asks Collection should start early enough to avoid destruction or contamination
Shared folders are fine for evidence Evidence storage should restrict unauthorized access, modification, and destruction

A.5.29 Information security during disruption

Trap Correction
Business continuity is only about restoring operations Security requirements must remain appropriate during disruption
Security can be relaxed informally during a crisis Emergency exceptions should be authorized, recorded, monitored, and reviewed
Disaster recovery plans automatically cover security Security objectives and responsibilities must be explicit
Supplier continuity plans are enough by themselves Supplier continuity arrangements should meet the organization’s security requirements
Testing is optional if the plan is detailed Complex continuity plans need practice and evidence of testing

A.5.30 ICT readiness for business continuity

Trap Correction
Backups equal ICT readiness Readiness also requires priorities, RTO/RPO, dependencies, playbooks, people, and testing
IT decides recovery order alone Recovery priorities should come from business continuity objectives and stakeholder input
RTO/RPO values are useful even if unrealistic Targets must be meaningful and achievable in the operational context
Supplier-hosted services are out of scope Supplier ICT continuity matters where the organization depends on supplier availability
A.5.30 can ignore confidentiality and integrity Availability recovery is not enough if the restored service is insecure; read it with A.5.29
Trap Correction
A legal register is enough Requirements must be owned, kept current, and mapped to controls and evidence
Contracts are legal team-only documents Security commitments in contracts must be extracted and implemented
Requirements change without affecting the ISMS Changes should trigger control, policy, evidence, or contractual updates where needed
Cryptography is only a technical choice Encryption, digital signatures, and electronic communications can have legal or jurisdictional requirements
International or online business is automatically covered Applicable jurisdictions and cross-border obligations may need specialist review

A.5.32 Intellectual property rights

Trap Correction
IP protection means only avoiding pirated software It also covers documents, designs, trademarks, patents, source code, libraries, subscription content, and AI-generated material
Software inventory proves compliance Inventory must be reconciled against licence terms and actual use
Developers can use any library they find Third-party and open-source licences should be reviewed before use
AI-generated content is automatically safe to reuse Provider terms, source material rights, confidentiality, attribution, and ownership need review
Copyright infringement is just a policy issue It can create contractual, civil, and criminal exposure depending on jurisdiction

A.5.33 Protection of records

Trap Correction
Records protection is just backup Records also need integrity, access control, retention, readability, and secure disposal
Keeping records for a long time is enough They must remain readable and usable until the end of retention
Encryption always solves records protection Key retention and future access must be planned
Scanned records are always legally equivalent Legal admissibility and integrity requirements may need review
Annual inventory checks are optional Required records should be checked and documented at least annually

A.5.34 Privacy and protection of PII

Trap Correction
Privacy equals confidentiality only Privacy also includes purpose, minimization, access, retention, transfer, rights, and breach handling
A privacy policy proves compliance Auditors need PII inventory, requirement mapping, controls, training, reviews, and evidence
PII means only customer databases PII may exist in exports, logs, support tickets, spreadsheets, backups, HR files, and supplier systems
Local law is the only requirement Contracts or client requirements can impose stronger PII protections
No recent breach means notification readiness is fine Notification obligations and escalation paths should be known before an incident

A.5.35 Independent review of information security

Trap Correction
Independent always means external Internal review can qualify if the reviewer is independent from the reviewed scope
Certification audit is unrelated A suitably scoped accredited certification audit can satisfy this control
Planned reviews are enough Significant changes should trigger supplementary review when criteria are met
Findings are enough Results should be recorded, reported to management, and tracked to corrective action
Review only means document review People, processes, technologies, approach, and implementation are in scope

A.5.36 Compliance with policies, rules and standards

Trap Correction
Compliance review is only internal audit Managers should review compliance in their own areas, and technical conformity checks may also be needed
Technical checks can be run by anyone Checks should be performed by competent, authorized personnel
Testing tools are harmless Some tools can disrupt systems or look like attack tools and must be controlled
Closing a finding means the issue is fixed Remedial action should be verified for desired effect
One technical issue is isolated by default Similar issues should be considered elsewhere

A.5.37 Documented operating procedures

Trap Correction
Experienced staff make procedures unnecessary Critical operations should not depend on memory or specific individuals
Procedures can be informal Operating procedures should be controlled formal documents where risk requires
Availability means stored somewhere Personnel who need procedures should know where to find the latest approved version
Supplier operations are outside scope Outsourced/network/cloud operations still need documented procedures and service expectations
More detail is always better Procedure detail should match size, complexity, risk, and frequency of use

A.6.1 Screening

Trap Correction
Screening means criminal-record checks only Screening can include identity, CV, qualifications, references, gaps, and role suitability checks where lawful and justified
Strongest screening for everyone is best Screening should be proportional to business need, information classification, law, ethics, and perceived risk
Contractors are outside the control Contractors, temporary staff, and third-party users can be in scope
Candidate-supplied CVs and certificates are enough Independent verification is stronger where permitted
Ongoing screening means constant surveillance Ongoing checks should be triggered by justified risk, role, or access changes and remain lawful
Screening evidence can be kept anywhere Screening records are personal data and need access, retention, and disposal controls

A.6.2 Terms and conditions of employment

Trap Correction
A confidentiality agreement alone satisfies the control Confidentiality helps, but terms should cover broader information security responsibilities
Only employees need security terms Contractors and third-party users in ISMS scope also need appropriate terms
Terms can be signed after onboarding Responsibilities should be accepted before work starts or before confidential access
Security responsibilities never need updating Role, access, facility, customer-site, or remote-work changes can require updated terms
The control only covers personnel duties The organization’s responsibilities, including personnel personal data handling, also matter
Remote work is unrelated Terms may need to cover home work, customer sites, outside-hours work, and post-employment duties where legally valid

A.6.3 Information security awareness, education and training

Trap Correction
Annual awareness training is enough Training should be appropriate to job function, responsibility, policies, procedures, and current threats
Awareness, education, and training mean the same thing Awareness reminds; education builds understanding; training builds role-specific capability
Only employees need training Contractors, third-party users, and relevant interested parties can be in scope
Attendance proves competence Stronger evidence includes role mapping, content, timing, assessment, interview results, and effectiveness review
Specialist staff can rely only on experience Experience or qualifications should be current, relevant, and verified where used instead of formal training
Training happens only at onboarding Refreshers and updates are needed after role, policy, procedure, threat, system, incident, or audit changes

A.6.4 Disciplinary process

Trap Correction
Every mistake requires disciplinary action Response should be evidence-based and proportionate
Informal manager action is enough The process should be formalized and communicated
Suspicion is enough to start action Sufficient evidence of breach or non-compliance should exist
Only employees are relevant Other relevant interested parties can be covered through contracts or agreements
Sanctions alone create security culture Incentives, training, and fair treatment also matter

A.6.5 Responsibilities after termination or change of employment

Trap Correction
This is only about leavers Role changes and contractor/third-party changes are also in scope where relevant
Disabling the user account is enough Physical access, assets, information, notifications, and continuing duties also matter
Movers only need new access added Old-role access should be removed unless still justified
Confidentiality ends on termination Continuing duties can remain valid where defined and legally enforceable
All terminations use the same urgency High-risk cases may need immediate access removal

A.6.6 Confidentiality or non-disclosure agreements

Trap Correction
A generic NDA for everyone is enough Agreements should reflect actual business, legal, contractual, and information security needs
NDA can be signed after disclosure It should be signed before access to confidential information
Only employees need NDAs Personnel and other relevant interested parties can be in scope
NDA replaces technical controls NDA supports confidentiality but does not replace access, classification, handling, and transfer controls
Legal review is optional in all cases Enforceability and legal conflicts may require specialist review

A.6.7 Remote working

Trap Correction
VPN satisfies the control VPN is only one control; endpoint, physical, access, data, and user controls also matter
Home work is automatically secure Home environments can expose information to family members and visitors
Public work has the same risk as home work Public locations increase shoulder-surfing, theft, paper, and conversation risks
Remote devices do not need inventory Equipment used for organization information should be tracked where relevant
All remote-accessible data is approved for remote work Remote access should be limited to required information and tasks

A.6.8 Information security event reporting

Trap Correction
Only confirmed incidents need reporting Observed or suspected events and weaknesses should be reported
Event reporting equals incident response Reporting feeds assessment and response; it is not the whole lifecycle
No reports proves no events It can indicate poor awareness or weak reporting culture
Security events are only technical Physical, paper, human, supplier, and privacy events can be reportable
Users should prove a weakness before reporting Users should not exploit or probe weaknesses without authorization

A.7.1 Physical security perimeters

Trap Correction
A locked front door satisfies the control Larger or higher-risk premises may need multiple internal security zones
Perimeter means only an external wall Internal rooms, floors, cages, archives, and customer zones can be perimeters
Physical security only protects against outsiders Internal personnel, visitors, cleaners, and contractors can also create risk
A floorplan proves the control Auditors need evidence that boundaries are complete and used
Shared building access is outside scope Landlord or building-management access can bypass the organization’s perimeter

A.7.2 Physical entry

Trap Correction
Physical entry is the same as perimeter A.7.1 defines boundaries; A.7.2 controls access points into secure areas
Visitor sign-in alone is enough Visitors may need badges, escorting, area restrictions, and exit logging
Badges work if staff do not wear them Badge discipline and challenge behavior are part of operation
Delivery areas are only logistics Delivery/loading routes can bypass secure areas and affect asset inventory
Physical access never needs review Physical access should be reviewed and removed like logical access

A.7.3 Securing offices, rooms and facilities

Trap Correction
A.7.3 is the same as A.7.1 A.7.1 defines perimeters; A.7.3 designs room/facility protection
Room labels are harmless Signs can reveal high-value targets
Internal directories are low risk Directories and phone lists can support social engineering and targeting
All rooms need the same controls Controls should reflect value, liability, importance, and classification
Specialized physical controls are always better Controls such as shielding need risk and operational justification

A.7.4 Physical security monitoring

Trap Correction
CCTV alone satisfies the control Monitoring needs response procedures, escalation, testing, and records
Physical alarms are facilities-only Information security may need involvement when information/assets are affected
False alarms do not matter Repeated false alarms weaken response and should be managed
Monitoring does not need testing Alarm and notification effectiveness should be tested
Alarm response is separate from incident management Physical breaches can be information security events or incidents

A.7.5 Protecting against physical and environmental threats

Trap Correction
Fire safety alone satisfies the control The control covers relevant physical and environmental threats to infrastructure
Only natural disasters matter Intentional and unintentional man-made threats also matter
Neighboring premises are irrelevant Neighbor hazards can affect the organization’s site and continuity
BCP is separate Fallback and backup arrangements should align to physical/environmental risk
Environmental controls are facilities-only They protect information assets, ICT services, and availability

A.7.6 Working in secure areas

Trap Correction
Badge access satisfies the control A.7.6 controls work practices inside the secure area
Secure-area rules apply only to employees Contractors, suppliers, visitors, and third parties need consistent rules
Mobile phones are harmless Phones can capture photos, video, audio, and messages
Dual control is always mandatory Dual control is applied where risk requires it
Need-to-know is optional Need-to-know limits unnecessary knowledge of sensitive work

A.7.7 Clear desk and clear screen

Trap Correction
Clear desk is just housekeeping It protects against disclosure, loss, damage, and misfiling
Clear screen means turning off monitors It means preventing unauthorized viewing or access, usually through locking
It applies only after work It applies during and outside working hours
Printers are out of scope Printers and fax machines can expose sensitive output
Same rule fits every area Controls should match classification and exposure risk

A.7.8 Equipment siting and protection

Trap Correction
Equipment protection means only server room locks It also covers workstations, screens, network devices, remote equipment, and environmental exposure
Environmental threats are only A.7.5 A.7.5 covers site threats broadly; A.7.8 applies protection to equipment siting
Clear screen fully covers visible screens A.7.7 defines behavior; A.7.8 considers physical screen placement and viewing angle
Remote equipment is out of scope Remote and networked equipment should be inventoried, scoped, risk-assessed, and protected
Electromagnetic shielding is always required Specialized controls require plausible, relevant risk justification

A.7.9 Security of assets off-premises

Trap Correction
VPN solves off-premises asset security Physical assets, paper, media, BYOD, custody, and loss/theft risk remain
BYOD is out of scope because the organization does not own it Organization information accessed from BYOD still creates risk
Insurance replaces security controls Insurance may reduce financial impact but does not protect confidentiality
Asset removal can be informal Removal of sensitive assets should be authorized and recorded
Off-site protection must always equal on-site protection It should be comparable where practical; differences need informed risk acceptance

A.7.10 Storage media

Trap Correction
Storage media means only USB drives It includes backup tapes, disks, removable drives, optical media, printed media, and similar carriers
Encryption alone solves transport Courier, packaging, authorization, records, and key separation also matter
Disposal is enough if a contractor signs a certificate The organization needs a satisfactory audit trail and contractor assurance
Damaged media can always be repaired Sensitive damaged media may need destruction instead of repair
Media controls are separate from classification Handling should follow classification and handling requirements

A.7.11 Supporting utilities

Trap Correction
Supporting utilities means only electricity It also includes cooling, telecoms, water, fire protection, emergency lighting, and related systems
UPS existence proves compliance Capacity, runtime, load, maintenance, testing, and cooling dependency matter
Generator protects all critical operations automatically Scope, fuel, load, cooling, maintenance, and tested runtime must match requirements
Public utilities can be assumed reliable Risk assessment should consider utility disruption
Building management systems are facilities-only In-scope BMS should be protected like other IT systems

A.7.12 Cabling security

Trap Correction
Cabling is only an availability issue Interception and tampering can affect confidentiality and integrity
Labels are cosmetic Labelling reduces incorrect connections and fault-tracing failures
Encryption replaces physical cabling protection Encryption can help, but physical protection and routing still matter
External provider junctions are out of scope They should be considered where they create risk
Power and data can always share routes Segregation may be needed to avoid interference

A.7.13 Equipment maintenance

Trap Correction
Maintenance only protects availability It also protects integrity and confidentiality
Correct operation means no maintenance is needed Equipment can fail suddenly without preventive maintenance
External maintenance access is harmless Maintainers may see data or modify equipment
Repair completion is enough Post-maintenance testing and tamper checks may be required
Maintenance is outside ISMS scope It is in scope when it affects information security

A.7.14 Secure disposal or re-use of equipment

Trap Correction
Deleting files is secure disposal Deleted files may be recoverable
Only computers contain storage Printers, CCTV, network devices, and embedded systems can store data
Encryption always solves disposal risk Key handling, encryption strength, and data sensitivity lifetime matter
Contractor certificate is enough The record should be traceable to specific assets/media
A.7.14 is the same as A.7.10 A.7.10 covers media lifecycle; A.7.14 covers equipment disposal/reuse containing media

A.8.1 User end point devices

Trap Correction
Endpoint security means anti-malware only It also includes patching, encryption, authentication, remote access, timeout, backup, storage, and user training
BYOD is out of scope Organizational information accessed from BYOD remains in scope
VPN alone protects endpoint use Device security, user authentication, storage, and loss/theft controls still matter
Screen timeout is only convenience It prevents misuse of unattended logged-in sessions
Mobile devices are only physical assets They are also technical access points into information systems

A.8.2 Privileged access rights

Trap Correction
Privilege is acceptable if the user is trusted Privilege still needs business need, approval, logging, and review
Full admin is easiest and therefore acceptable Least privilege should be used where possible
Emergency privilege can be informal Emergency access needs procedure, logging, review, and restoration checks
Shared admin accounts are efficient They weaken accountability
Privileged access review is enough Actual privileged activity should also be logged and reviewed

A.8.3 Information access restriction

Trap Correction
Access restriction only means login control It includes application roles, data access, menus, reports, exports, print, and maintenance utilities
Application roles are enough Shared databases, reporting tools, and exports can bypass application roles
Users can see restricted functions as long as access is blocked Restricted functions should normally be hidden or unavailable
Exported data is outside the control Extracted information should follow the same classification and handling rules
Dynamic support access is only a privileged access issue It must also be controlled when it exposes information or functions

A.8.4 Access to source code

Trap Correction
Protecting Git is enough Development tools, CI/CD, libraries, macros, reports, and production copies also matter
Read access to code is low risk Source code can reveal system design and security controls
Production systems can store source code for convenience This should be avoided or strongly justified and controlled
Libraries are outside the control Software libraries are explicitly part of the control

A.8.5 Secure authentication

Trap Correction
Password plus PIN is MFA It is usually repeated single-factor authentication
Authentication errors should be detailed for usability They should not reveal account existence or system details
A.8.5 is the same as A.5.17 A.5.17 handles authentication information; A.8.5 tests the authentication mechanism
Legacy authentication gaps can be ignored They need risk assessment and compensating controls

A.8.6 Capacity management

Trap Correction
Capacity means disk space only It includes compute, storage, network, databases, cloud limits, and people
Cloud removes capacity management Cloud still has quotas, cost limits, scaling behavior, and bottlenecks
Monitoring proves capacity management Trend analysis, forecasting, and action are also needed
Staff capacity is unrelated Inadequate staffing can degrade security operations and availability

A.8.7 Protection against malware

Trap Correction
Antivirus installation proves compliance Coverage, updates, monitoring, response, and awareness evidence are also needed
Malware is only a Windows endpoint issue Many operating systems and device types can face malware risk
Automatic cleaning is always enough Serious infections may require wipe/rebuild and verification
User awareness is optional Awareness is explicit in the control requirement
Free security tools are acceptable by default Tools should be approved and suitable for the risk

A.8.8 Management of technical vulnerabilities

Trap Correction
Running a scanner proves compliance Findings must be risk-rated, treated, retested, and reported
A.8.8 is only patch management It starts with vulnerability information and exposure evaluation
Penetration testing replaces scanning Penetration testing can supplement the vulnerability process
All patches must be installed immediately Timing should be risk-based and consider uptime/resilience
Open vulnerabilities can stay open informally Exceptions require risk acceptance, owner, and review date

A.8.9 Configuration management

Trap Correction
Configuration management means asset inventory It means baselines, implementation, monitoring, and review
Vendor baselines can be copied unchanged They often need local risk-based tailoring
Automation eliminates configuration risk Exceptions, operational impact, and drift still need management
Alerts prove monitoring is effective Alerts must be triaged, escalated, and resolved
Deviations are always nonconformities Deviations can be acceptable when risk-assessed and compensated

A.8.10 Information deletion

Trap Correction
Deletion means physical destruction only Secure deletion, cryptographic erasure, application deletion, and media destruction may all apply
Retention policy proves compliance Deletion records and method suitability are needed
Items awaiting destruction are low risk They must be protected like active information
Cloud data cannot be deleted Cloud deletion needs provider-supported process and evidence
Keeping everything is safer Over-retention increases privacy, legal, and breach impact risk

A.8.11 Data masking

Trap Correction
Masking deletes data Masking usually hides data while the original still exists
Pseudonymised data is anonymous It can be re-linked with a lookup table or key
Anonymisation is easy True anonymisation is hard because combinations of fields can identify people
Lookup tables can stay with tokenized data They should be segregated and protected
Re-combined data can be kept for convenience It should be protected and deleted when no longer needed

A.8.12 Data leakage prevention

Trap Correction
DLP means buying a DLP tool Tooling supports broader data-flow governance
Blocking every transfer is the goal Approved business flows must operate securely
False positives are only technical noise They affect control effectiveness and audit evidence
Authorized transfer is always acceptable Channel, encryption, approval, and risk appetite still matter
Users do not need DLP awareness Users must know approved sharing and reporting routes

A.8.13 Information backup

Trap Correction
Backup success proves recovery Restore tests prove recovery
Backups are only data files Software, systems, configurations, and dependencies may also need backup
Backups need less protection than originals Backups often contain full sensitive data and need equivalent protection
Cloud means backups are automatic Cloud backups/snapshots still need scope, retention, testing, and protection
Archives are useful if retained They must remain readable with required software, media, and key dependencies

A.8.14 Redundancy of information processing facilities

Trap Correction
Every system needs full redundancy Redundancy should be based on availability requirements and risk
Backup is the same as redundancy Backup supports recovery; redundancy supports availability/failover
Cloud automatically satisfies redundancy Cloud design still needs scope, architecture, testing, and evidence
Redundancy means duplicate servers only Networks, storage, power, locations, identity, logging, and dependencies may matter
Redundancy reduces all risk It can introduce replication, synchronization, and access-control risks

A.8.15 Logging

Trap Correction
Logging means storing event files Logs must also be protected and analysed
More logs always means better security Useful risk-based logging and analysis matter
Administrators can review their own logs Separation of duties should be used where possible
SIEM presence proves compliance Coverage, rules, alert review, and escalation matter
Fault logs are only operational Faults can affect integrity and availability and need corrective action

A.8.16 Monitoring activities

Trap Correction
Monitoring is the same as logging Logging records events; monitoring detects anomalies and potential incidents
SIEM/IDS/IPS presence proves compliance Rules, source coverage, thresholds, triage, tuning, and escalation matter
Provider default rules are enough Rules need review in organizational risk context
More alerts means better detection Alert fatigue can reduce detection quality
Only perimeter traffic needs monitoring Identity, endpoints, cloud, applications, and critical systems may also need coverage
In-hours monitoring is enough Out-of-hours escalation must be defined where relevant

A.8.19 Installation of software on operational systems

Trap Correction
This applies only to custom code Vendor software, libraries, utilities, patches, and packages can also be in scope
Developer competence is enough Production installation still needs authorization, testing, logging, and rollback
Emergency changes do not need records Emergency changes still need recording and post-implementation review
Backup alone proves recoverability A fallback or rollback strategy should be defined and usable
Licence checks are not security Licence and support status affect legal, operational, and vulnerability risk

A.8.20 Networks security

Trap Correction
Network security means firewall rules Architecture, zoning, routing, device management, monitoring, encryption, and changes also matter
Physical networks are enough Virtual networks, cloud networks, hypervisors, and management planes are in scope where relevant
Diagrams prove control Diagrams must match actual configuration and operation
Admin networks are automatically trusted Administrative paths can bypass zoning and need strong control
Fault monitoring is enough Potential breaches must be detected, reported, and followed up

A.8.21 Security of network services

Trap Correction
Provider network service means provider-owned risk The organization must identify, agree, and monitor required security features
Uptime SLA is enough Confidentiality, integrity, and security controls also matter
Standard provider package always satisfies the control Provider limitations may need compensating controls or risk acceptance
Failover is continuity-only Security levels should remain appropriate during failover and recovery
Contract signing proves operation Service features and levels must be monitored

A.8.22 Segregation of networks

Trap Correction
Perimeter firewall satisfies segregation Internal and logical zones may also be required
VLAN labels prove segregation Enforced routing/firewall/security group controls matter
Wireless is separate by default Wireless connection to the main network needs risk assessment
Segregation must be physical Logical segregation can be acceptable if effective
Performance exceptions can be informal Security-impacting changes need approval and review

A.8.23 Web filtering

Trap Correction
Web filtering is only productivity control The ISO control focuses on reducing malicious content exposure
Awareness is enough Technical filtering helps because users make mistakes
Vendor categories define policy Categories should be chosen based on risk and business need
Exceptions are harmless Exceptions need authorization and review
C2 attempts are just browsing violations They may indicate compromise and should feed monitoring or incident handling

A.8.24 Use of cryptography

Trap Correction
Encryption automatically satisfies the control Rules, approved methods, and key management are required
Stronger crypto is always better Strength must fit risk, performance, legal, and operational needs
Public keys need no protection Public keys and certificates need integrity and replacement protection
Secret algorithms are safer Home-grown or secret algorithms are normally a serious weakness
Key escrow is automatically acceptable Escrow needs authorization, awareness, monitoring, and abuse prevention

A.8.25 Secure development life cycle

Trap Correction
Secure SDLC means only secure coding It also covers environments, training, review, tools, suppliers, and standards maintenance
Automated scanning proves compliance Findings, standards, competence, and remediation matter
Contractors can use their own rules Third parties should meet the organization’s secure development rules
Code author review is enough Competent independent review is expected where risk requires it

A.8.26 Application security requirements

Trap Correction
Secure coding covers application requirements A.8.26 is requirements; A.8.25 is lifecycle rules
Vendor applications need no requirements Acquired applications also need security requirements
Generic requirements are sufficient Requirements should be specific, approved, and testable
Approval can wait until go-live Requirements should be approved early enough to shape design or selection

A.8.27 Secure system architecture and engineering principles

Trap Correction
Secure coding standard satisfies A.8.27 A.8.27 is broader: architecture and engineering principles
Principles only apply to new software They apply to information system development activities broadly
Zero trust alone satisfies the control Principles must fit the organization and be applied
Documentation is enough Design records should show principles influenced decisions

A.8.28 Secure coding

Trap Correction
Secure SDLC and secure coding are the same A.8.25 is lifecycle rules; A.8.28 is coding principles
Automated tools prove secure coding Tools support verification but do not replace standards and review
One generic standard fits all code Language, framework, and risk context matter
AI-generated code is inherently safer Generated code still needs secure review
Legacy constraints justify informal bypass Exceptions should be documented and approved

A.8.29 Security testing in development and acceptance

Trap Correction
Functional testing is enough Security tests, regression, defective input, and control tests matter
Final penetration test is enough Testing should occur through the lifecycle
Findings can be ignored for go-live Findings need remediation, retest, or risk acceptance
Acceptance is only business sign-off Security acceptance criteria and authorization matter
User testing is only usability Users may try to bypass controls; secure use should be tested or trained

A.8.30 Outsourced development

Trap Correction
Supplier owns development, so supplier owns security The organization remains accountable for accepted systems
A contract alone satisfies the control The organization must direct, monitor, and review development activity
Functional acceptance is enough Supplier deliverables need security review and testing evidence
Only direct suppliers matter Subcontractors and indirect supply chain dependencies can create risk
IP ownership is separate from security IP, licence, and ownership terms affect control and future maintainability

A.8.31 Separation of development, test and production environments

Trap Correction
Dev/test/prod names prove separation Actual access, network, identity, data, and deployment controls must enforce separation
Test data is harmless Production data in test can carry production-level sensitivity
Developers need standing production access Standing access weakens integrity and accountability
Only production needs strong controls Development and test need controls appropriate to their risk
CI/CD automatically enforces separation Pipelines can bypass separation if permissions and approvals are weak

A.8.32 Change management

Trap Correction
Approval alone is enough Impact assessment, testing, rollback, logging, and review are also needed
Change management only applies to code Systems, infrastructure, networks, cloud, facilities, and operational environments can be in scope
Emergency changes are exempt Emergency changes still need control and retrospective review
Release notes replace change records Release records should identify the underlying changes
Functional testing is enough Security control and vulnerability impact should be considered

A.8.33 Test information

Trap Correction
Test data is low risk because it is outside production Sensitivity follows the data, not the environment
Anonymisation always removes risk Re-identification and masking quality matter
Only the test database needs control Logs, caches, screenshots, reports, and debug files can leak data
One approval covers all live-data testing forever Live-data use should be justified and authorized per occasion
Deleting the main test table is enough Copies and secondary outputs also need handling

A.8.34 Protection of information systems during audit testing

Trap Correction
Auditors can test anything by default Operational testing needs scope, agreement, and safeguards
Audit testing is risk-free Scans and tools can disrupt systems or expose information
Only penetration testing needs authorization Assurance tools, scans, and extracts can also require approval
Audit results are normal records Results can expose vulnerabilities and system details
Internal audit planning covers this automatically This control focuses on protecting operational systems during testing
  • Exam
  • Iso27001
  • Iso27002
  • Traps

Note Metadata

Aliases: Exam Traps

Source: 03 Exam Prep/Common Exam Traps.md