A testing programme beats one-off tests: a risk-based calendar (crown jewels tested more often/deeper; compliance and change-driven tests as floors), coverage across app, infrastructure, cloud and people (phishing, red team), a repeatable provider & scoping process, a remediation & retest workflow, and board reporting by risk and trend, not raw counts. Regulatory floors (PCI annual/change; NCA CSCC six-monthly for critical systems) set minimums the risk plan must meet or exceed. Most run a primary provider plus occasional independent engagements. The goal: security as a measurable, improving capability. Playbook below.
// 01 Programme, not project
The shift that defines a mature security function is moving from “we did a pentest” to “we run a testing programme.” A single test is a snapshot of a defined scope at a point in time; the attack surface it examined has already changed by the time the report lands. A programme treats testing as a continuous process against a moving target: a planned calendar, defined coverage, a repeatable provider and scoping process, a remediation workflow, and reporting that shows posture trending. That's what converts disconnected events into a measurable, improving capability - and it's what a board, an auditor and a demanding customer actually want to see. Everything below is how a CISO builds that.
// 02 The risk-based calendar
The backbone is a risk-based testing calendar. Map the attack surface, rank assets by data sensitivity and exposure, and schedule accordingly: crown-jewel systems (the ones holding regulated or business-critical data) tested more often and more deeply; lower-risk systems on a longer cycle; and mandatory tests pinned to compliance deadlines and significant changes. Crucially, regulatory requirements set floors, not ceilings: PCI DSS requires annual and change-driven testing; the Saudi NCA CSCC requires six-monthly testing of critical systems; the CBB and SAMA regimes set their own cadences. Your risk-based plan must meet or exceed every applicable floor. Map them all with the GCC compliance calendar and the requirements finder.
// 03 Coverage: what the programme spans
Adversary simulation
Red teaming for maturity - testing detection and response, not just prevention.
A programme escalates in ambition over time: start with the highest-risk applications, broaden to infrastructure and cloud, add people, and graduate to red teaming once prevention is solid - the natural maturity path.
// 04 Closing the loop: remediation & providers
A programme lives or dies on what happens after the report. Findings must flow into a tracked remediation workflow with owners and SLAs (criticals fast), a prioritisation method so effort targets real risk, and a retest to prove closure - a finding logged but unfixed is just a future breach on record. On the supply side, run a repeatable provider process: a consistent scoping approach, providers chosen on quality not price, and clear data-handling terms. Most CISOs run a primary provider for continuity and environment knowledge, with occasional independent engagements for a fresh perspective (different testers find different things) or specialist red teaming. The management overhead drops sharply once scoping, reporting format and remediation tracking are standardised.
// 05 Reporting posture to the board
The final discipline is upward reporting, and it's where many technically strong programmes under-sell themselves. Boards don't want raw finding counts - they want risk and trend. Frame results in business terms: what the most serious findings could have cost or exposed, how fast they were remediated, and whether posture is improving - fewer criticals recurring, faster remediation, expanding coverage. A single trend line - “critical findings down, remediation time down, coverage up” - communicates more to a board than any table. Presenting testing as a measurable programme with a trajectory, rather than a pass/fail event, gives the board the assurance and risk visibility it needs - and reframes the security budget as an investment with evidence behind it, exactly the case made in the board-asks-about-security and ROI guides.
// 06 Frequently asked questions
Test vs programme - what's the difference?
A test is a single engagement against a defined scope at a point in time. A programme is the ongoing, planned process to test a changing attack surface continuously: a risk-based calendar, defined coverage across app/infra/cloud/people, a repeatable provider and scoping process, a remediation and retest workflow, and board reporting on trend. The programme turns individual tests into a measurable, improving capability.
How does a CISO decide what and when to test?
Risk-based. Map the attack surface, rank assets by data sensitivity and exposure, and set a calendar: crown jewels tested more often and deeper, lower-risk systems on a longer cycle, and mandatory tests tied to compliance deadlines and significant changes. Regulatory requirements (PCI annual/change, NCA CSCC six-monthly for critical systems) set floors the risk plan must meet or exceed.
How should a CISO report to the board?
By risk and trend, not raw counts. Frame results in business terms: what serious findings could have cost or exposed, how fast they were remediated, and whether posture is improving over time (fewer recurring criticals, faster remediation, expanding coverage). A programme with a trend line gives the board the assurance and risk visibility it needs.
One provider or several?
A single trusted provider offers continuity, environment knowledge and simpler management, suiting most programmes. Some rotate or add a second for a fresh perspective, and higher-assurance needs may use a separate provider for red teaming or a specialism. A common model is a primary provider for the recurring programme plus occasional independent engagements, chosen on quality not lowest price.