The CISO’s Real 2027 Problem Is Not More Threats. It Is Time to Decision.
There is an easy conclusion to draw from the 2026 threat landscape: attacks are getting faster.
That conclusion is true, but not particularly useful.
For a CISO, the more consequential question is this:
Can the organisation see, decide and contain a material cyber event at the speed its operating environment now requires?
That is not predominantly a threat-intelligence question. It is a question of operating readiness.
The distinction matters.
In Singapore, scam losses fell 17.9% year on year in the first half of 2026, to approximately S$410.6 million. That is real progress. Yet the Singapore Police Force also reported that online platforms remained the first point of contact in 89% of scam cases.
At the vulnerability layer, the pressure is different. VulnCheck found that 23.43% of known exploited vulnerabilities in the first half of 2026 showed evidence of exploitation on or before the day their CVE was published. Median time from CVE publication to known exploitation also fell from 120 days in 2025 to 80 days in H1 2026.
But there is an important nuance CISOs should not miss: It is also found that early exploitation did not increase at the same rate as CVE issuance. Of 1,061 vulnerabilities attributed to AI-assisted discovery, just 14, or 1.3%, had been confirmed as exploited in the wild.
So the lesson from 2026 is not “AI means every vulnerability is now an emergency.”
It is almost the opposite.
More signals, faster discovery and more automation increase the premium on deciding correctly what matters.
Microsoft reaches a related conclusion in its 2026 Digital Defense Report. It describes attack timelines as compressing, with AI being applied across vulnerability discovery, reconnaissance, phishing, malware and exploit development, data analysis and post-compromise activity.
That changes the CISO problem.
The organisation cannot solve a velocity gap simply by consuming more intelligence. It has to reduce the organisational distance between knowing something has changed and being able to act on it.
Challenging the top five questions for 2027:
Own: Who owns identity risk?
See: Can we see service exposure?
Contain: Can we contain threats quickly?
Restore: Can we restore trusted services?
Prove: Does intelligence remove exposure?
The five questions are more useful as an operating model than as a security checklist.
1. OWN: Identity risk now crosses organisational boundaries
The old mental model of identity was largely internal: employees, administrators, service accounts and privileged users.
That boundary is becoming less useful.
SaaS platforms, cloud services, suppliers and AI-enabled tools can all sit in the path between a business process and the information or permissions needed to execute it.
The governance problem appears when these access paths exist but nobody clearly owns the resulting decision.
The roundtable frames the gap directly: cloud, supplier and AI tools create access risks that no one tracks. Its recommended response is not simply another identity product. It is to establish decision ownership, maintain an inventory of systems, suppliers and tools together with their access and data lineage, and incorporate access risk into approval of new tools and suppliers.
The CISO question
Not “Do we have IAM?”
Ask:
For every identity or tool capable of materially changing a critical service, who owns the decision about what it is allowed to do?
That shifts identity from administration to accountability.
2. SEE: Asset visibility is not the same as service visibility
Most mature organisations have inventories.
Fewer can take a critical business service and rapidly show every technology, supplier and data dependency necessary to keep it operating.
That distinction becomes important during an incident.
A vulnerability scanner can tell the SOC that an internet-facing component is exposed.
It cannot necessarily tell the incident commander:
Which critical service depends on it?
Which supplier operates it?
What data passes through it?
What breaks if it is isolated?
Whether a connected AI capability sends information elsewhere?
Therefore, mapping systems and suppliers against critical services, asking suppliers where their products send organisational data, including built-in AI functions, and prioritising known exploited vulnerabilities in internet-facing systems.
When almost a quarter of observed KEVs show exploitation evidence by CVE publication day, remediation queues based simply on CVSS plus age are increasingly difficult to defend.
For the CISO, visibility becomes useful only when it shortens a decision.
A 50,000-item asset inventory is less operationally valuable during a crisis than knowing exactly which twelve dependencies can interrupt the payment, manufacturing, customer or authentication service you are trying to protect.
3. CONTAIN: Prevention without a reliable stop mechanism is incomplete
Security teams spend enormous effort controlling how systems start doing something.
Less attention is often paid to whether the organisation can make them stop.
That becomes more important as automated systems are given greater autonomy.
The roundtable asks organisations to test three capabilities:
just-in-time access and human approval for high-impact activity;
the ability to pause a system or tool safely, including work in progress;
leadership rehearsal of an account-takeover scenario.
None of those controls assumes that AI itself is malicious.
The issue is blast radius.
An authorised account, integration or automated workflow can perform legitimate actions at a speed and scale that becomes damaging once the identity or process is compromised.
A useful 2027 test
For every highly privileged automated service, ask:
If its behaviour becomes unsafe at 10.12am, who can stop it at 10.13 am, and what business process breaks when they do?
If the answer requires finding three system owners, opening a supplier ticket and convening a change board, the organisation does not have machine-speed containment.
It has a machine-speed risk connected to a human-speed decision process.
4. RESTORE: A successful backup test is not proof of service recovery
Backup assurance and business-service recovery are related. They are not equivalent.
A technically successful restore proves that data or a system can be recovered under the conditions tested.
The business needs something harder:
Can the organisation restore a trusted service, within an acceptable time, when one of its dependencies has become unavailable or untrusted?
Timed restoration tests, including supplier-run services, plans for continuing operation when a supplier or tool must be paused, and an inventory supporting the future transition of long-lived sensitive data toward quantum-safe protection.
The supplier point is especially important.
A recovery exercise that assumes every third party is functioning normally tests the infrastructure.
It may not test the crisis you actually need to survive.
A stronger exercise deliberately removes a critical dependency and measures:
detection time;
decision time;
isolation time;
minimum-service restoration time;
full trusted restoration time.
Those numbers tell the CISO considerably more than “the backup completed successfully.”
5. PROVE: Security activity is not evidence of reduced business risk
This may be the most important question of the five.
Security organisations generate enormous quantities of evidence:
alerts investigated;
vulnerabilities closed;
phishing messages blocked;
incidents handled;
endpoints covered;
threat-intelligence reports consumed.
Those measures demonstrate work.
They do not automatically demonstrate that the organisation is safer where it matters.
This identifies the problem plainly: organisations can end up reporting activity rather than whether their biggest business risks are shrinking. It recommends showing the board quarterly which risks have fallen and which remain, and linking security spending to the services and risks it protects.
This same principle appears in ONESECURE's Singapore digital-trust research. The State of Digital Trust in Singapore 2026 argues that discovery alone is insufficient when external identity conditions continually change. The operational problem is determining what deserves attention, when a change becomes material and who owns the resulting decision.
That is a useful model beyond external digital identity.
Intelligence has value when it changes exposure, prioritisation or action.
The board therefore needs fewer reports that say:
We processed 15,000 alerts.
And more that say:
This quarter our exposure on Service X moved from A to B. These two dependencies remain outside tolerance. This investment reduces one; management has accepted the other until Q3.
That is evidence of risk management rather than security activity.
The common thread: compress the decision loop
Look again at the five questions:
Own → See → Contain → Restore → Prove.
They appear to describe different security disciplines.
Operationally, however, they address the same weakness:
How much organisational friction sits between evidence and action?
Microsoft's 2026 report argues that intelligence only matters when teams can action it.
That should alter where CISOs look for maturity gaps.
The bottleneck might not be the SOC.
It may be unclear ownership.
It may be a dependency nobody mapped.
It may be an automated identity nobody can rapidly suspend.
It may be a supplier whose isolation procedure has never been exercised.
Or it may be a reporting model that tells leadership how much security work occurred without showing whether material exposure actually decreased.
Threat velocity is therefore not purely a detection problem. It is a decision-system problem.
