CISM — Frequently Asked Questions

The systems must be addressed through a formal risk acceptance / exception process rather than being left silently non-compliant. If a patch cannot be applied (e.g., the vendor no longer ships patches for an end-of-life product, or the patch would break a critical business application), the control owner should implement approved compensating controls (network isolation/segmentation, a proxy, virtual patching, additional monitoring) and document a risk exception signed off by the accountable business/data owner or the CISO. CISM stresses that a documented, approved exception with compensating controls is acceptable, whereas an undocumented policy violation left unmanaged is not. Forcing an immediate disruptive patch or simply powering the system off is incorrect without a risk-based decision by the risk owner.

The BCP should be maintained through an ongoing change management and periodic review process. The single most effective mechanism is to integrate BCP updates into the organization's change management process and the Business Impact Analysis (BIA) refresh cycle, so that whenever business processes, systems, personnel, vendors or the threat landscape change, the plan is revised accordingly. The plan should additionally be formally reviewed and tested at least annually and after significant changes, with lessons learned from tests and real incidents fed back into revisions. Treating the BCP as a static document that is only revisited after a disaster is the classic failure mode.

The best defense is a layered, upstream traffic-scrubbing and capacity strategy rather than a single on-premises device. Because DDoS attacks exhaust bandwidth and resources, the most effective measure is to engage the ISP or a cloud-based DDoS mitigation (scrubbing) service that filters malicious traffic before it reaches the enterprise perimeter, combined with redundant bandwidth, anycast distribution, content delivery networks and rate limiting. A firewall or IPS alone is insufficient because it cannot absorb volumetric attacks. So the priority answer is outsourced/cloud DDoS mitigation with ISP cooperation, supported by internal rate limiting and a prepared response plan.

A BCP is primarily triggered when a disruption threatens or causes the unavailability of critical business functions that cannot be recovered within their acceptable downtime (Recovery Time Objective, RTO) using normal operations - that is, when there is a real or imminent loss of a vital business capability (or a life-safety situation). The trigger is based on the assessed business impact (loss of a critical process/system beyond tolerance), NOT merely on any IT outage with no business consequence. Activation is typically decided by a designated crisis management team against pre-defined criteria derived from the BIA.

The best approach is to communicate in business terms, focusing on business impact, risk and value rather than technical detail. Security issues should be presented through business-relevant, quantified metrics and risk indicators (potential financial loss, regulatory exposure, reputational impact, risk versus appetite) so executives can make informed decisions. Translating technical findings into business consequences and aligning them to strategic objectives is what makes the communication effective; reporting raw vulnerability counts or technical jargon is the least effective method for this audience.

That decision belongs to the control owner / business process owner (the risk owner) in consultation with relevant stakeholders - not the IT or security team alone. Because a control mitigates a specific risk, the owner of that risk (the business/data owner) is accountable for accepting residual risk or approving changes, normally through a formal change management / risk acceptance process and with input from the CISO or information security manager. The security manager advises and facilitates, but accountability for the risk decision rests with the business owner who accepts the risk.

The DRP is made effective through regular, realistic testing combined with clearly defined roles and up-to-date documentation. The single most important practice is conducting periodic recovery tests/exercises (including failover testing) to validate that procedures, RTOs/RPOs, personnel, contacts and alternate-site resources actually work, then correcting the gaps found. A well-written but untested plan provides only false assurance, so testing and exercising - and using the results to update the plan - is the strongest assurance of effective execution.

The strongest facilitator is having a clear supporting information security policy (and standards) as the foundation, derived from business objectives and risk assessment, and closely involving the operational staff / process owners who will execute them. Procedures describe the specific step-by-step tasks that implement policy and standards; when the underlying policy hierarchy, standards and management support exist and are aligned to business processes, procedures are far easier to write and to keep relevant. Management support and a sound governance framework are therefore the best enablers.

The first step is to understand the business - its mission, objectives, processes, and how information and IT assets support them, together with the applicable legal/regulatory environment. Only after understanding business goals and the supporting assets can the security strategy be derived to protect them and enable the business. Conducting this business/strategic analysis (establishing the link between business goals and IT/information resources) precedes gap analysis, benchmarking or control selection; without understanding the business objectives, alignment is impossible.

The most important quality is that the metrics are relevant and aligned to business objectives and risk - that is, they measure what matters to the business and support decision-making, rather than merely what is easy to measure. Executive-level metrics should be tied to business impact, risk posture and the program's contribution to business goals, and be quantifiable over time to show trends. Technically interesting but business-disconnected metrics give the board little value, so business relevance and alignment is the priority.

The best input is a risk-based cost-benefit analysis: the quantified risk exposure (expected loss / probability and impact of exploitation) versus the cost of the mitigating control. This translates the technical vulnerability into a business decision, showing the financial impact of the risk and demonstrating that the proposed control reduces that risk at a justifiable cost. Citing only vendor advisories, CVSS scores or compliance checklists is weaker, because management decides on the basis of risk versus investment.

The strongest indicator is that information security is embedded in the organization's overall governance structures - e.g., a formal, board-/senior-management-endorsed security strategy and steering committee, with security roles, responsibilities and risk accountability defined and integrated into corporate decision-making and performance management, and security aligned with the enterprise risk management framework and business objectives. When security has executive sponsorship, sits on the corporate governance/steering committee and ERM, and reports into corporate governance, integration is demonstrated rather than security operating as an isolated IT function.

Readiness is validated through a progression of tests: checklist/tabletop (structured walkthrough), simulation, parallel (including partial failover) and full operational / full-interruption testing. The most thorough is full-interruption testing, which actually shifts operations to the alternate site. Appropriate testing verifies that the plan, procedures, resources, personnel and recovery objectives (RTO/RPO) actually work in practice. CISM emphasizes that testing at varying depths is the primary means of confirming readiness and uncovering gaps, with results feeding lessons learned and plan updates.

The most important consideration is the availability/compatibility risk of the site - specifically the risk that the shared site may already be occupied by another company when a regional disaster strikes, and that its configuration/hardware may not match your environment within your RTO. For a shared warm/cold site, capacity contention (first-come-first-served during a widespread disaster) and compatibility with your systems are the greatest concerns; you must secure contractual guarantees of availability and compatibility that meet your recovery requirements. Cost matters, but guaranteed availability and compatibility when you actually need it are decisive.

The greatest concern is loss of confidentiality and control over sensitive personal/salary data, and ensuring the vendor adequately protects that data and complies with applicable privacy/regulatory requirements. CISM focuses on whether the contract and controls ensure the provider safeguards confidentiality, applies appropriate security controls, permits audits and defines liability; the risk is that confidential HR/personal data could be mishandled, disclosed or processed in non-compliant ways. Vendor due diligence plus contractual security/privacy/confidentiality clauses and audit rights are therefore the priority.

The best method is to measure and review the program using business-aligned indicators and governance feedback - that is, perform a gap analysis of the security program against business objectives and enterprise strategy, and use business-relevant KPIs/KRIs reviewed with business stakeholders and the steering committee. Alignment is confirmed when security goals are derived from and traceable to business objectives and when business owners acknowledge that security enables (rather than hinders) their goals. Industry benchmarking or purely technical metrics are less direct than measuring alignment to the organization's own stated business goals.

The essential practice is that the forensic workstation must not be connected to the network (to avoid contaminating or altering evidence) and must work only on verified, write-protected forensic images of the original media, using validated, documented, write-blocked tooling that preserves chain of custody. The original media is preserved untouched, and integrity (e.g., cryptographic hashes) is verified before and after analysis so findings are admissible. In short: isolated workstation, work on verified copies, maintain chain of custody and integrity - never analyze the original directly on a networked machine.

The most effective approach is to embed security requirements throughout the vendor lifecycle: perform security due-diligence/risk assessment during selection, contractually specify enforceable security controls, audit/right-to-inspect clauses, incident-notification and compliance obligations, and then continuously monitor the vendor's security performance over time. Contractual security clauses plus ongoing monitoring and periodic audits (not a one-time assessment at onboarding) give the strongest assurance; relying on the vendor's self-assertion alone is insufficient.

The most important aspect is that the plan is current, practical and validated - that defined roles/responsibilities, escalation paths, thresholds and communication procedures are clearly assigned, aligned with business priorities, and verified through testing/exercises so the team can actually execute it. Equally important is coverage of the full incident lifecycle (containment, eradication, recovery, post-incident lessons learned) and integration with business continuity/crisis management. An untested, out-of-date plan, or one lacking clear authority and roles, is the key weakness to identify during review.

Evidence integrity is preserved by following a disciplined, documented forensic process: establish and maintain chain of custody, avoid altering the system more than necessary for containment, capture volatile data (memory, active connections, logs) first, then acquire a verified forensic image of the storage using write-blockers, and compute cryptographic hashes before and after acquisition to prove the evidence was not tampered with. Analysis is performed on the copy, never the original, and all actions are logged. Preserving chain of custody and demonstrating integrity through hashing is what keeps the evidence admissible.