Prepared by: The Triskele Labs Governance, Risk and Compliance (GRC) team | Published: 13 October, 2026
The GRC team at Triskele Labs works with boards, executives and security teams across the Australian and New Zealand market, delivering governance, risk and compliance programs that reflect how organisations actually operate. Through Security Team as a Service we embed experienced cyber security specialists directly into client organisations, providing the expertise of a mature internal security function without the cost of building one, and reporting to the board on the risks that matter to that business.
GOVERNANCE, RISK AND COMPLIANCE · STATE OF CYBER 2026
Engagements this year turned up a consistent pattern: the most common finding wasn't a missing control. It was one nobody had tested since it went in.
What has changed:
What you'll learn in this article: why organisations are asking whether their controls work rather than whether they exist, what control debt actually looks like inside an environment, and how GRC is becoming the coordinator of governance across the enterprise.
The question our GRC team is asked most often has changed. For years it was whether a control met a standard. This year it was whether the control works.
That is a considerably harder question, and organisations asking it is the most encouraging shift we have seen in this practice. Once a client asks whether something works, someone has to go and find out.
Demand for GRC work held across the year, spanning governance, risk and compliance engagements for clients of every size. What moved was the shape of it.
Security Team as a Service now accounts for a quarter of GRC engagements, up from 15 per cent last year, and for the first time it is our single most-requested engagement. Over the same period, the proportion of clients receiving direct board reporting rose ten per cent year on year.
Both figures describe the same decision. Clients want embedded cyber subject matter experts who understand their environment and can brief their boards directly on the threats they face, rather than an assessment delivered as a document and read by nobody. Security is being treated as a standing responsibility rather than a purchase.
This is a market maturing. A board that receives direct reporting asks better questions than a board that receives a summary, and an adviser who sits inside an environment for a year can answer questions an adviser visiting for a week cannot. The two changes reinforce each other.
Across our engagements this year we repeatedly found tooling that had been bought, deployed and signed off as complete, and not tested since to confirm it works in the environment it landed in. We call this control debt, and it was the most consistent finding of the year.
It is not a new problem. It is a growing one, and it is growing quietly, because every year adds tooling to an environment and nothing in a conventional compliance program sends anyone back to check what was bought the year before. A control correctly deployed two years ago and drifting since is indistinguishable, on a risk register, from one operating exactly as intended. The register records the decision to buy, not the evidence that it works, so the board reading it is given a more reassuring picture than the environment supports.
Control debt is showing up more often not because environments got worse, but because more clients asked us to look. Point-in-time assessment against a standard was never designed to answer whether a control operates day to day, and for as long as that was the dominant engagement, control debt sat outside what anyone had been engaged to see. Embedded work looks at the environment as it runs, and it finds what a scheduled assessment was never scoped to find.
Discovering control debt is not evidence that a security program has failed. It is evidence that the organisation has started asking a question its previous assurance model could not answer, and the organisations doing that are ahead of the ones still reporting green.
Through client discussions this year, AI risk became the fastest-rising question raised with our team, and the nature of it changed as it rose. A year ago clients asked where AI could speed the business up. This year they ask what it exposes once it is inside the environment.
AI impact assessments are set to become a standard requirement for understanding that exposure, these answer a short set of questions most organisations cannot currently answer with confidence: what data a model can reach, what actions it is permitted to take, who approved that permission, and what happens when it acts wrongly. Those questions are answerable before deployment and considerably more expensive to answer afterwards.
The organisations commissioning these assessments now are doing so before an incident forces the question, which is the same instinct driving the shift in engagement mix. They are the same clients, asking the same thing about a newer technology.
A pattern we year on year is organisations underestimating the volume and value of the data they held, and how exposed it was. Data treated internally as routine record keeping is often exactly what makes an organisation worth attacking.
One exercise shifts that assessment faster than any maturity review. Rather than asking what data the organisation is obliged to protect, ask what a threat actor would want from it, what it would be worth to them, and how much of it could be reached from a single compromised account. The answer is almost always larger than the risk register suggests, because the register was built around regulatory categories rather than around value to an attacker.
Clients who run that exercise tend to reprioritise quickly, and what they reach for is consistent: knowing where the data lives, restricting who can reach it, and noticing when volumes of it leave. It is a short list, it is cheaper than most tooling, and it is available to an organisation of any size.
Several weaknesses have not moved, and the pace of the threat has made them more expensive to leave alone.
Patching still lags, and many organisations are not actively identifying their vulnerabilities in the first place, which makes the lag impossible to measure and impossible to prioritise. AI-enabled attackers have sharply cut time-to-exploit, so prioritised patching is now non-negotiable rather than routine maintenance.
Identity and access gaps persist. Weak or inconsistently applied multi-factor authentication and poor lifecycle management remain common, and privileged access management remains a recurring area of weakness rather than an isolated one.
What these have in common is not a lack of awareness. In most environments we assessed, every one of these was already named, with a policy covering each. The failure is follow-through: an exemption granted for one system quietly becomes permanent, a privileged account outlives the project it was created for because nobody owns the review, a control applied to most of an estate reports as implemented while the remainder goes unrecorded. Each is a governance failure before it is a technical one, which is why the shift towards embedded advisory work matters more than any individual control on this list.
GRC is increasingly being asked to coordinate governance across the enterprise, and the AI boom has accelerated that. When a business adopts a technology faster than it can write the rules for it, someone has to hold the total picture rather than the individual items, and increasingly that is the GRC function. This is the clearest sign that the discipline has moved past its origins as a compliance exercise.
The same technology carries a caution. Organisations are leaning on AI to draft governance documents at speed, and many of those documents go unchecked by a human. The result is a shadow risk: material that reads well, satisfies a reviewer at a glance, and does not meet the organisation's real needs. Governance produced faster than it can be reviewed is a control that has never been verified, in a newer format.
Advice is only useful if it is practical, accessible and grounded in the environment an organisation actually runs rather than an ideal-state architecture. Held to that standard, the response is a short list.
None of this requires a larger security budget. It requires knowing what the organisation holds, what is working and who is accountable.
The direction of travel across our client base this year was good. Organisations bought expertise rather than artefacts, put it in front of their boards, and asked harder questions of technology they had already adopted.
What that shift exposes is uncomfortable in the short term, because a question nobody was asking tends to have an unflattering answer the first time it is asked. It is also the only route to an assurance model that reflects the environment as it runs rather than as it was documented. The organisations that will be in the strongest position next year are the ones already able to answer, this quarter, whether a control is working everywhere it is meant to be.