You didn't download this because your security programme is failing. You downloaded it because you're responsible for one that has to keep working — under more regulatory pressure, with more attack surface, and with a board that expects answers in plain English.
What follows isn't a product catalogue. It's the kind of information that tends to surface in post-incident reviews, when everyone is asking why nobody said it before things went wrong.
Five things. All of them real. All of them fixable. Plus one that almost no security vendor will tell you about — because the answer to it doesn't require buying their product.
Your Biggest Breach Risk Isn't a Zero-Day
The security industry has a talent for making the complicated feel urgent and the mundane feel manageable. The result: most enterprise security programmes are better defended against sophisticated nation-state attacks than they are against the credential a contractor never returned.
The statistics are consistent. The majority of confirmed breaches begin with compromised credentials — not exploited vulnerabilities, not zero-days. A valid username and password, used by someone who shouldn't have it.
In large enterprises, the attack surface for credential-based breach is substantial: former employees whose accounts were never fully deprovisioned, contractors with temporary access that became permanent by inaction, service accounts with broad permissions created for a project that ended, shared credentials used across teams because individual provisioning was "too slow."
None of these appear in a penetration test conducted against your production environment. All of them represent genuine, present exposure.
Conduct a dead accounts audit. Cross-reference your active directory against your HR offboarding records for the last 24 months. The gap between "account deactivated" and "access fully revoked across every downstream system" is where stale credentials live. In most enterprises with 1,000+ employees, this audit surfaces meaningful exposure within hours.
Review service account permissions. Service accounts are created with broad permissions because scoping them properly takes time nobody has. They rarely get reviewed. Audit yours against the principle of least privilege — the ones with domain-admin equivalent access that nobody can explain are your priority.
Treat identity hygiene as a quarterly control. The velocity of change in most enterprises — M&A, restructuring, contractor churn — means annual reviews leave months of exposure unaddressed.
Your MFA Can Still Be Phished
Most enterprises now have MFA in place. Most of it can still be phished.
Push notification fatigue attacks, adversary-in-the-middle proxies that intercept OTP codes in real time, SIM swapping — these aren't theoretical vectors. They're the methods behind the majority of credential-based breaches in regulated industries right now.
The problem isn't that organisations lack MFA. It's that the MFA they have depends on a shared secret — a code, a push notification, an SMS — that can be intercepted or socially engineered.
Phishing-resistant authentication uses cryptographic binding between the credential, the user's verified device, and the specific domain being accessed. There is no shared secret to intercept. A fake login page cannot request or use the credential. Push fatigue attacks have nothing to push.
The technology is mature, FIDO2-compliant, and deployed at scale in financial services, government, and critical infrastructure. It is also cheaper to run than the legacy MFA it replaces — particularly compared against per-user Okta or Microsoft Entra licensing at enterprise scale.
Before your next MFA renewal or identity platform review, ask your vendor one question: Is this authentication method phishing-resistant under NIST AAL2/AAL3 standards? If the answer involves OTP codes, push notifications, or SMS — the honest answer is no. The replacement path is deployable without hardware tokens and costs materially less than most organisations currently spend.
Your AI Tools Are Processing Data They Shouldn't
Every enterprise AI adoption programme creates the same problem. It doesn't announce itself. It accumulates quietly — across productivity tools, co-pilot assistants, and document processing platforms, all of which were approved individually and implemented quickly.
The result: sensitive data — customer records, personal identifiers, health data — is being ingested by AI systems that were not designed with that data in mind, processed in environments that your data governance programme did not anticipate, retained in ways that may not align with the consents you obtained when you collected it.
The technical answer is tokenisation: sensitive data is pseudonymised before it enters any AI pipeline. The model receives statistical utility. The individual identity never enters the system. No breach surface. No notification obligation. The AI programme continues without restriction.
This approach was applied for a government-backed healthcare organisation aggregating patient data from multiple hospitals for AI-driven drug discovery. Tokenisation made the programme possible while protecting patient identity — an answer no standard security vendor in the room could offer.
Map your AI tool estate. For every tool that processes text, documents, or data, identify what data types it handles and where that data goes. Where sensitive data enters an AI pipeline, establish the legal basis and implement a technical control — tokenisation — that ensures the data cannot be individually identified even if the pipeline is compromised.
Your Incident Response Plan Has Never Been Tested Under the Rules That Now Apply
Most enterprise incident response plans were written before NIS2 and DORA came into force. Most have been tested in tabletop exercises where everyone knew it was a test. None of that preparation maps cleanly onto what is now legally required.
In most organisations, the gap between "someone noticed something" and "the CISO is aware" is hours. The gap between "the CISO is aware" and "legal, comms, and the board are aligned" is days. The gap between "we have a response" and "we have a regulatory notification ready" is rarely measured at all.
Run your incident response plan against the NIS2/DORA clock. Map every step against the 24-hour and 72-hour windows. Where does the process break? Who is the single point of failure?
Establish a notification-ready template in advance. The 24-hour early warning requires notification, preliminary assessment, and incident type — not a full report. This can be templated and pre-approved before an incident happens. Almost no organisation has done this.
Ensure your board understands personal liability explicitly. Not as a general awareness point. Specifically: Article 20 of NIS2. Most board-level cyber briefings do not cover this adequately.
Your Security Programme Was Designed for Last Year's Threat Model
The threat landscape that most enterprise security programmes were built to address remains real. It has also been joined by a set of risks that most programmes haven't fully incorporated.
Supply chain attacks. Your security controls trusted the software because it was legitimately signed. The attacker entered through the vendor's update channel, not yours.
AI-accelerated phishing. Personalised, contextually accurate phishing emails — previously the mark of sophisticated targeted attacks — are now producible at scale. Your email filtering was tuned against last year's average quality.
Insider data exfiltration via AI tools. An employee who wants to take customer data does not need a USB drive. They need a prompt. Most DLP controls were not designed for this vector.
Regulatory divergence. Operating across UK, EU, and Middle East means GDPR, NIS2, DORA, and UAE PDPL simultaneously. What satisfies one framework may not satisfy another. The operational burden of managing them separately is substantial.
Run your supply chain dependency audit. Map software with privileged access or update channels into your environment. Update your threat model annually — as a genuine reassessment, not a documentation exercise. And if you operate across EU, UK, and Middle East geographies, the regulatory matrix requires dedicated cross-jurisdictional attention.
Nobody Has Single Accountability for Security, Privacy, and AI Governance Simultaneously
Everything in the previous five sections can be addressed by a sufficiently resourced, experienced security team. The technology exists. The frameworks are documented. The solutions are deployable.
What nobody talks about: most enterprises don't have a single point of accountability for cyber security, data privacy, and AI governance simultaneously. The CISO owns security controls. The DPO owns data privacy. The CTO or CDO owns AI adoption. Each operates in their lane.
A data exfiltration event via an AI tool is simultaneously a security incident, a GDPR breach, and an AI governance failure. The regulatory notifications differ by framework. The remediation involves all three functions. The board wants one answer.
The organisations that handle this well have one thing in common: a single external partner who sits across all three domains and can translate between technical reality, regulatory obligation, and the board conversation. That is what we built Paringa to be.
What Happens Next
The honest version.
There are three things worth doing this quarter:
If you'd like an independent assessment, we're happy to have that conversation — no commitment required.