Policy Ownership and Stakeholder Coordination at a Payments Firm

ISO/IEC 27032 guidance treats cybersecurity policy as a top-management instrument that sets scope, objectives, roles, risk approach, incident coordination and review. LumenPay's policy is a technical procedure in policy clothing. Defect 1: authorship and scope. IT wrote it around passwords and firewalls, so it lacks business, legal, supplier and customer commitments. Defect 2: accountability. Naming the CIO as owner merges service delivery with security oversight; the CISO needs authority to challenge releases and escalate risk. Defect 3: lifecycle and incident interface. No review cycle and service-desk handling mean no regulatory 72-hour process, no major-incident decision rights, and no link to risk appetite. The 'zero trust' slogan is not a control model or policy. A revised framework should have a board-approved cybersecurity policy, supporting standards and procedures; define risk appetite; assign roles; require annual and event-driven review; and connect to supplier and incident management. The test is whether a reader can tell who decides, who is consulted, and how the policy changes when the regulator or threat landscape changes.

Use RACI explicitly: R does the work, A answers for the decision, C is consulted, I is informed.

• Accept high residual risk: A = board/audit committee within appetite; R = CISO for assessment and recommendation; C = CIO, CFO, business owner, legal; I = internal audit.
• Declare major incident: A = CISO for cybersecurity severity; R = incident commander; C = CIO, legal, compliance, affected business head; I = CEO and regulator via legal.
• Approve release exception: A = CISO; R = application security lead; C = CIO, product owner, risk; I = audit. Reasoning: accountability must sit with the role that can stop or accept the activity, not with a committee that never sees releases. The CIO can be consulted but should not accept security risk on the CISO's behalf. The board sets appetite and accepts only risks above operational thresholds. This separation prevents the current ambiguity and gives the regulator a clear notification decision path.

Create a Cybersecurity Steering Committee chaired by the COO or CEO, with the CISO as secretary, and members from CIO, CFO, compliance, legal, procurement, HR, and business-unit leads. Meet monthly and after any major incident. Inputs: risk register and appetite breaches, incident trends and near misses, supplier assessments for the 12 critical suppliers, regulatory changes and 72-hour readiness, control metrics, audit findings, and threat intelligence relevant to payments. Outputs: decisions on risk treatment and exceptions, policy and standard changes, resource allocation, incident exercise schedule, and actions with owners and dates. Escalation triggers: a residual risk above appetite that no business owner will accept, or an incident with regulatory notification, customer funds impact, or likely media exposure. The forum should not replace the incident team; it governs readiness and improvement. This design connects the board's slogan to decisions, gives the CISO a coalition rather than sole responsibility, and creates evidence for the audit committee.