When did your organisation last answer these honestly? When did you last commission a full GRC and external OSINT audit — and was the result robust, or robust only on paper? When did you last test what happens when a breach is actually declared? And if one were declared this afternoon, would every owner named in your response plan know their role without reaching for a document?
If those answers do not come quickly, you are not unusual — but you are exposed. The ServiceNow disclosure in June 2026 is a sharp reminder of why. The real question it raised for most teams was not whether the platform had a flaw, but whether they would even know if it had caught them. ServiceNow notified only the customers it had flagged. No notification meant no news — which is not the same as no exposure.
Public detail is still limited, and the advisory went to customers privately rather than out in the open. We cannot tell you whether your organisation was affected; only ServiceNow and your own logs can. This piece is about something more useful: the gap the incident exposes in almost every organisation we assess — a gap of governance as much as security — and how you close it.
We are still fighting the last war
None of this is new, and that is the uncomfortable part. We have written before about why Australia keeps suffering the same breach, year after year: organisations keep hardening a perimeter they had already secured, while attackers move on to identity, people and trusted third parties. It catches the well-resourced and the well-certified as readily as anyone else, because the blind spot is structural, not a failure of effort. The ServiceNow exposure is that same war in a new uniform.
It also shows why the two things most often sold as modern protection do not help here. Security AI is built to spot the unusual — but a stolen login used by an attacker does not look unusual, so it passes straight through. And governance, when it is just a certificate on the wall or a software subscription, proves you followed a process; it says nothing about what you are actually exposing right now.
What actually happened
The instinct on reading a breach headline is to ask which patch was missed. That instinct does not fit here. Nothing was unpatched, because there was no known vulnerability to patch. The problem was simply how one endpoint was set up to respond — it answered requests before checking who was asking.
An endpoint answered without authentication. A request-handling API endpoint could be reached without any login or token. It was a configuration mistake, not a flaw in the software — so there was no known vulnerability for signature-based detection to recognise.
Instance data could be queried. With nothing checking who was asking, an unauthenticated request could read the tables behind the platform — the live store of IT tickets, employee records, asset inventories and incident reports.
Support tickets were the real prize. Service-desk tickets routinely hold credentials, API tokens and internal notes pasted in while troubleshooting. The data an attacker wants most was not locked away — it was sitting in ordinary records.
Stolen logins look like normal use. A password or token taken from a ticket is a valid credential. An attacker using it looks like an authorised employee — so behavioural and AI-driven tools have nothing unusual to flag.
You only knew if they told you. ServiceNow applied a fix on 5 June 2026 and notified only the customers it had flagged. If you were not contacted, you were left to assume you were unaffected.
Every step used the platform much as it was designed to work. The single failure was one door left answering questions it should have refused.
Why this lands on your desk, not the vendor's
What matters is not the endpoint itself, but what it could reach. Your ServiceNow instance holds the working record of your organisation — tickets, asset inventories, employee records, incident reports. And tickets are where secrets quietly pile up: an API token pasted in to reproduce a fault, a password shared to unblock a colleague.
None of that is locked in a vault. It sits in ordinary records your people created in good faith. The vendor runs the platform, but the risk inside it — and the duty to manage that risk — stays with you. Outsourcing the work never outsourced the accountability.
This is a governance gap, not a technical one
AI and governance both have their place, but neither is a substitute for the actual work. A certificate shows you followed a process; it does not tell you what you run, what it exposes, or who owns that risk. Answering those three questions is the real work of governance — and no tool or badge answers them for you.
Could you, today, produce a current list of every platform that holds your data, and say for each one what it exposes and who is responsible for it? In most organisations that list lives in people's heads, not a register — and where a register does exist, it rarely records exposure or ownership at all. That is the gap this incident exposes: your footprint is not just unmapped, it is ungoverned. It is also the first thing an attacker maps, because the outside view is the only one they have.
In a mature risk model, a platform holding your employee records and incident history would not sit in a procurement folder. It would sit on your risk register with four things attached: a named owner, a likelihood-and-impact rating, the controls meant to contain it, and a clear statement of the risk you have accepted. Yet most registers we review list third parties by how much they cost — not by the data they hold or the access they have. Fixing that is not a product you buy. It is risk modelling, and it is the discipline this incident calls for.
What an external view gives you — and the line it will not cross
Here we want to be plain about the limits of what we do, because the limits are the point. We could not have caught the ServiceNow flaw, and no external assessment can. We do not touch your systems, and we never would. What an external view does is different, and more lasting: it means that when a vendor lets you down — and one eventually will — you are not starting from nothing.
Using only public sources, it shows you the same picture an attacker builds before they pick a target — your organisation, seen from the outside:
What an external view can establish for you
- Which platforms you run, confirmed from public certificate and DNS records — including instances your own team may have forgotten.
- Which of your login pages, interfaces and services are reachable from the internet, and where that footprint is bigger than you assumed.
- Where your staff credentials already appear in public breach and infostealer data, measured as a real attack surface.
- How your vendors and suppliers look from the outside — the third parties whose exposure quietly becomes yours.
When it surfaces something visible that deserves attention, the right response is not alarm. It is a specific check you hand to your team or your vendor: confirm this is meant to be reachable, that it requires a login, and that access is limited. We define the question precisely; you and your provider answer it. We observe, we frame, we recommend, and we never overstate — which is the whole reason an assessment can be trusted.
The obligation is yours, even when the vendor stays silent
This is where the incident stops being the vendor's problem and becomes yours in law. Under the Notifiable Data Breaches scheme, the duty to assess a suspected breach and notify those affected falls on the organisation that holds the data — not on the platform that processes it. If a vendor notifies only some of its customers, your obligation does not pause for the ones it skipped.
And enforcement is no longer theoretical. The first civil penalty under the Privacy Act — A$5.8 million against Australian Clinical Labs in October 2025 — turned on a failure to protect data, not on how clever the attacker was. "Our vendor did not tell us" is not a defence. "We already knew our exposure, governed it, and acted" is. The gap between those two sentences is the entire value of being prepared — and it is exactly the position a proper assessment puts you in.
What you walk away with
A BlackFlag engagement is not a tool you run or a dashboard you watch. It pairs a passive external assessment with the governance modelling that turns what we find into a position you can defend. Within days, you have:
- your external exposure set out as risk — each finding rated for likelihood and business impact, and assigned to an owner, not just listed;
- your platforms and vendors placed on a risk register with named owners and an agreed risk position — ready to govern, not rediscover in a crisis;
- the secrets sitting in everyday records identified and flagged for rotation, whatever any single vendor does next;
- findings mapped to your obligations under the Notifiable Data Breaches scheme and the Australian Privacy Principles;
- a report your board and your engineers can both read, saying plainly where you stand and what to check next.
The point is simple: when the next vendor incident lands, you are already governed and able to answer your board and your regulator — not scrambling to work out what you run while a notification clock is already ticking.
What to do before the next one
The perimeter you may still picture — a network edge, hardened and watched — is no longer where your business lives. It lives in platforms you license but do not control, reached through identities and trusted suppliers. The ServiceNow exposure is not a freak event. It is a preview, and there will be more like it.
So treat composure as a decision, not a hope. It comes down to three deliberate moves. Map what you run and what each platform exposes. Model that exposure as risk you own — rated, assigned, and tied to your obligations. Then govern it as carefully as you govern your own systems, and treat the secrets in everyday records as the assets they are. Done once, properly, that work turns the next vendor incident from a scramble into a question you can already answer.
That is the work we do — passively, independently, and in plain enough terms that your board can act on it. The organisations that come through the next exposure intact are not the lucky ones; they are the ones who mapped, modelled and governed it first. If you cannot say today what your platforms expose and who owns that risk, do not wait to be told the way ServiceNow's customers were. Find out now, on your terms.