CISM interview questions

Auditors test for evidence, not intent: show the access-review policy, dated records of each review with approver sign-off, and confirmation that flagged access was revoked and verified. A verbal confirmation proves nothing repeatable, a promise to start next quarter shows the control was not operating in the audit period, and an org chart describes reporting lines, not access decisions. Only the dated, attributable artifacts demonstrate the control operated as designed across the whole period.

Backups are necessary but not sufficient: disaster recovery and business continuity are the tested capability to restore operations within agreed recovery time and recovery point objectives (RTO/RPO), which requires a documented plan, mapped dependencies, runbooks, and validated restores — not just the existence of backup files. Agreeing they're the same conflates a data copy with an operational capability. DR isn't merely buying insurance, which transfers financial loss but doesn't restore systems. And backups don't make a DR plan unnecessary — untested backups routinely fail when they're finally needed. The clarification: DR must be exercised, not assumed.

Frameworks set a minimum bar and can be fully met while real risk remains, so a passed checklist doesn't mean secure: raise the gap, assess its risk, and drive treatment regardless of the compliance status. Concluding it's secure because compliance passed is a dangerous conflation of two different things. Removing the gap from the report is misrepresentation and potentially fraud. Waiting for the next audit cycle knowingly leaves a real exposure open. The mature stance treats compliance as evidence of a floor, not a ceiling, and acts on risk you can actually see.

Inconsistent handling usually means there's no shared definition of sensitivity, so the foundational control is a data classification scheme (e.g., public/internal/confidential/restricted) with defined handling, storage, and sharing requirements per level, letting teams apply proportionate controls. Encrypting nothing 'to keep things simple' or treating all data as public strips protection from data that needs it. Deleting all data older than a day destroys records the business and the law require. Only a classification scheme aligns the strength of controls to the actual sensitivity of the data.

Leaver risk is lingering access, so the control to verify is timely deprovisioning of every access path — directory accounts, SSO, VPN, privileged and service credentials, and third-party SaaS — reconciled against the joiner/mover/leaver (JML) process. Assuming HR handles it all without verification leaves gaps no one owns. Keeping the account active 'in case they come back' is standing, unmonitored risk. Disabling only email ignores the many other systems the person could still reach. The point is to verify access is actually and fully removed, not to trust that it was.

PCI DSS scope covers systems that store, process, or transmit cardholder data plus anything connected to or able to affect them, so effective network segmentation isolates the cardholder data environment (CDE) and removes unrelated systems from scope, shrinking cost, effort, and risk. Encrypting every server doesn't define a boundary and connected systems stay in scope; adding untargeted firewalls everywhere isn't segmentation if it doesn't restrict and validate the data flows; and stopping people reading card numbers aloud is hygiene, not a scoping control. The systemic answer is to control where cardholder data lives and what can reach it.

Governance means the risk is captured and managed, not informally handled: record it in the risk register with assessed likelihood and impact, assign an accountable owner, decide and document the treatment (mitigate, transfer, accept, or avoid), and set a review date. Fixing it yourself on the spot skips ownership, prioritisation, and tracking, and may not even be your call. Ignoring it until it becomes an incident is negligent, and emailing everyone creates noise but no accountability or follow-through. The register turns a one-off observation into a tracked, owned, revisited decision.

A SOC 2 report only assures you if you actually read it: confirm it's the right type (Type II tests operating effectiveness over time, Type I only design at a point), check the scope and which Trust Services Criteria it covers, that the period is current and has no gap, what opinion the auditor gave (unqualified vs qualified), and review the noted exceptions plus the complementary user-entity controls (CUECs) you're responsible for. Merely confirming the report exists — or judging it by its cover logo or page count — tells you nothing about the vendor's actual control effectiveness or your residual obligations.

Sending PII to a third party extends your trust boundary, so first run a vendor security assessment — data handling, encryption, access controls, certifications like SOC 2 / ISO 27001, sub-processors, breach-notification terms — and put a data-processing agreement (DPA) in place before any PII flows. A pricing contract or a sales rep's verbal word is not due diligence. And a 'polished website' tells you nothing about how the vendor actually protects data; you remain accountable for it.

'Secure' is not binary; a CISO communicates in business-risk language: the most material risks, how current controls reduce them relative to the board's risk appetite, planned investments, and the residual risk being accepted. An absolute 'yes' is false assurance that collapses the moment an incident happens. 'No, we'll never be secure' is technically true but unhelpful and signals no command of the problem. A shopping list of firewalls and tools conveys spending, not risk or outcomes the board can actually govern.

Breach handling is governed by law and contract: work with legal to meet mandatory notification timelines (such as GDPR's 72 hours to the supervisory authority) and inform affected parties accurately. Concealment risks far larger fines, regulatory action, and reputational damage when it surfaces later. Dumping raw, unverified technical details prematurely can mislead customers and aid attackers. Scapegoating an individual employee is neither accurate, lawful, nor effective crisis management — it deflects from the organization's accountability.

Board-level metrics should connect to risk and outcomes: detection and response times (MTTD/MTTR), patching-SLA adherence on critical systems, control coverage, and how residual risk trends against appetite. The number of attacks blocked by the firewall, antivirus signature counts, and total emails received are vanity numbers — they sound impressive but tell leadership nothing about whether risk is going down. The board governs risk, so metrics must let them see the trend and decide.

A 30% click rate is a baseline to improve, not a list of people to punish: pair role-based training and a frictionless report button with technical defenses (MFA, email filtering, least privilege) so a single click doesn't lead to compromise, and track the trend over time. Publicly shaming employees suppresses the reporting you depend on. Declaring the workforce hopeless removes a control you should be strengthening. Another scary all-staff email isn't a measurable intervention and doesn't change behavior.

Security spend should follow risk, not hype: use a risk assessment to direct money where business impact and likelihood are highest and current control coverage is weakest, then measure the reduction you achieve. Buying whatever the popular vendor sells ignores your actual threat profile and often funds shelfware. Spreading the budget evenly underfunds the few areas that matter most. Copying competitors assumes their risk profile equals yours, which it rarely does.

Tabletops rehearse the human and decision side of IR — who has authority to declare an incident, how legal/PR/exec communication flows, and where the playbook breaks — so the first time you make those calls isn't during a real crisis. It's far cheaper to find gaps in a drill than mid-breach. They are not a hollow compliance checkbox, they're not for assigning blame for past incidents, and they are cross-functional, not SOC-only — leadership has to practice the decisions only they can make.

When you can't remediate, you manage the risk: reduce exposure with compensating controls (network segmentation, tightened access, enhanced monitoring), quantify the residual risk, and have the accountable business owner formally accept it with a defined review date. Unilateral shutdown oversteps the CISO's authority and harms the business. Ignoring it because it can't be fixed is negligence. Omitting it from the risk register hides accountability, breaks audit trails, and means no one is on record owning the decision.

A vendor breach is your incident too: invoke incident response to scope which of your data and integrations were exposed, rotate any shared secrets, API keys and SSO trust, evaluate your own regulatory notification duties, and hold the vendor to disclosure. Passively waiting for the vendor cedes control of your own timeline and obligations. A public contract termination is premature theatrics before you even know your exposure. Assuming you're unaffected skips exactly the assessment that regulators and your own customers expect.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, risk-based framework for governing trustworthy AI across its lifecycle. Its core is four functions: Govern (culture, policy, accountability — and it runs through the others), Map (context and risk identification), Measure (assess and track risks), and Manage (prioritize and respond). It also defines trustworthiness characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair. It complements technical lists like the OWASP LLM Top 10 at the program level.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

Quantitative analysis assigns hard monetary values so you can compute expected loss; qualitative analysis ranks risk on relative scales (high/medium/low) using expert judgment. Quantitative uses SLE = asset value x exposure factor, ARO = expected occurrences per year, and ALE = SLE x ARO to express annual expected loss in dollars.

You can mitigate (reduce likelihood/impact with controls), transfer (shift the financial impact via insurance or contracts), avoid (stop the risky activity entirely), or accept (knowingly tolerate the residual risk). The choice depends on risk appetite and a cost-benefit comparison against the risk's expected loss.

Controls are classified two ways. By type: administrative (policies, training, procedures), technical/logical (firewalls, MFA, encryption), and physical (locks, badges, cameras). By function: preventive (stop an event — MFA, access control), detective (find an event — SIEM, IDS, audit logs), corrective (fix after — restore from backup, patch), deterrent (discourage — warning banners), and compensating (an alternative when the primary control isn't feasible). Defence in depth layers these so no single control failure leads to compromise.

GDPR Article 5 sets seven principles: lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. For a personal data breach, the controller must notify the competent supervisory authority without undue delay and where feasible within 72 hours of becoming aware (Article 33). If the breach is likely to result in a high risk to individuals, the controller must also notify the affected data subjects without undue delay (Article 34).

Governance is how leadership sets direction, defines accountability, and aligns security with business objectives — the policies, roles, and oversight that say what 'good' looks like. Risk management is the process of identifying, assessing, treating, and monitoring threats to those objectives. Compliance is demonstrating adherence to obligations — laws, regulations, contracts, and internal policy. Governance drives risk decisions; risk informs which controls you need; compliance evidences that those controls meet required standards. Compliance is an outcome of good GRC, not a substitute for security.

HIPAA (the US Health Insurance Portability and Accountability Act) protects Protected Health Information (PHI). The Privacy Rule governs use and disclosure of PHI; the Security Rule applies to electronic PHI (ePHI) and requires three categories of safeguards — administrative, physical, and technical. It applies to covered entities (providers, health plans, clearinghouses) and to business associates that handle PHI on their behalf, bound by Business Associate Agreements. The Breach Notification Rule sets obligations to notify individuals, HHS, and sometimes the media.

ISO/IEC 27001 specifies the requirements for an Information Security Management System (ISMS): a risk-based, top-down framework of policies, processes, roles, and continual improvement (Plan-Do-Check-Act) governing how an organisation manages information security. Annex A is a reference catalogue of controls. You don't apply them all blindly — you run a risk assessment, decide which controls are needed, and document the include/exclude decisions with justification in a Statement of Applicability (SoA).

The NIST Cybersecurity Framework organises cybersecurity outcomes into core functions. In CSF 2.0 there are six: Govern (the new overarching function for strategy, roles, risk decisions, and oversight), Identify (understand assets and risks), Protect (safeguards to limit impact), Detect (find events), Respond (act on incidents), and Recover (restore capabilities). They are not strictly sequential — they run continuously and together describe a full lifecycle of managing cyber risk.

PCI DSS (Payment Card Industry Data Security Standard) is a security standard maintained by the PCI Security Standards Council that applies to any organisation that stores, processes, or transmits cardholder data. It is organised around control objectives covering a secure network, protection of stored cardholder data, vulnerability management, strong access control, monitoring/testing, and an information security policy. Scope is everything in the cardholder data environment (CDE) — so segmentation, tokenisation, and not storing data you don't need are the main ways to shrink scope.

Treat awareness as behaviour change, not an annual checkbox. Make it role-based (a developer needs different content than finance), continuous rather than a once-a-year slideshow, and grounded in real risks like phishing, social engineering, and data handling. Reinforce it with phishing simulations, just-in-time nudges, and clear reporting channels. Measure outcomes — phishing report rates, click rates, time-to-report — not just completion percentages. Build a culture where people report mistakes without fear, because fear suppresses reporting.

A KPI (Key Performance Indicator) measures how well a security activity is performing against its objective — for example mean time to detect, patch SLA compliance, or percentage of systems with MFA. A KRI (Key Risk Indicator) is a forward-looking signal that risk exposure is increasing toward an unacceptable level, with a threshold that should trigger action — for example the number of overdue critical patches, count of unmanaged devices, or failed access reviews trending up. KPIs tell you how you're doing; KRIs warn you about where you're heading.

A SOC 2 Type I report assesses whether a service organisation's controls are suitably designed at a single point in time. A Type II report goes further: it tests whether those controls operated effectively over a review period, typically 3 to 12 months. Both are based on the AICPA Trust Services Criteria — Security (the required common criteria), plus optional Availability, Processing Integrity, Confidentiality, and Privacy.

Treat vendor risk as a lifecycle, not a one-off questionnaire. Inventory your third parties and tier them by criticality and data sensitivity. Run due diligence proportional to tier — review SOC 2 / ISO 27001 reports, security questionnaires, pen-test summaries, and the data and access involved. Bake controls into the contract (security requirements, right to audit, breach notification, data handling, subprocessors). Then monitor continuously, not just at onboarding, and have a clean offboarding process to revoke access and recover or destroy data. Fourth-party (subprocessor) risk matters too.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.