DISC InfoSec blog

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

MachineLearning & Artificial Intelligence

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation: info@deurainfosec.com

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: iso 27001, NIST CSF

DISC-AI-Governance-Readiness-Assessment-1-1 pdf download Download

Jul 27 2026

Continuous NIST 800-53 Compliance: How to Stop Failing in the Eleven Months Between Audits

Category: Information Security,NIST CSF,Security Compliance — disc7 @ 7:33 am

Continuous NIST 800-53 Compliance: How to Stop Failing in the Eleven Months Between Audits

Most organizations do not fail NIST SP 800-53 during the assessment. They fail three months after it, quietly, and only find out the following year when an assessor pulls a sample and the sample doesn’t hold.

The pattern is always the same. A team spends four months assembling a System Security Plan, closes findings in a sprint, gets a favorable Security Assessment Report, and then goes back to shipping product. Accounts drift. Baselines drift. Scans get acknowledged instead of remediated. The POA&M becomes a graveyard of “in progress” line items with completion dates in the past. Twelve months later the control catalog hasn’t changed — the environment has.

This post is about the operating model that prevents that: what NIST 800-53 compliance is actually worth to a business, how often it genuinely needs to be assessed, and how to run it as a continuous process instead of an annual fire drill.

Part 1 — What NIST 800-53 compliance is actually worth

SP 800-53 Rev 5 is the control catalog mandated for federal information systems under FISMA. But the business case for a private company adopting it usually has nothing to do with FISMA.

Market access. This is the honest headline. SP 800-53 is the substrate underneath FedRAMP (Moderate/High baseline plus overlay parameters), CMMC 2.0 Level 2 (via SP 800-171, itself derived from the Moderate baseline), and most agency-specific security requirements you’ll see in a federal contract or subcontract flow-down. If you want to sell to a federal agency, a systems integrator, or a prime, this isn’t a differentiator — it’s the door.

Procurement leverage in the commercial market. Enterprise and financial-services security questionnaires increasingly ask questions that are 800-53 controls wearing a different hat. Being able to answer “here is our AC-2 implementation, here is the evidence, here is the ODV we assert and the metric that proves we hold it” shortens diligence cycles measurably. Security review is a sales-cycle line item; control maturity is how you shorten it.

Framework reuse. This is the underrated one. One well-run 800-53 Moderate program feeds ISO 27001:2022 Annex A, SOC 2 Trust Services Criteria, CSF 2.0, PCI DSS, and the HIPAA Security Rule with substantial overlap. The catalog is a superset of most of what your other auditors will ask for. Organizations that build the evidence pipeline once and map outward spend a fraction of what organizations spend running four parallel compliance programs with four sets of screenshots.

Risk reduction that survives contact with reality. The control families that generate the most audit findings — AC (access control), CM (configuration management), RA (vulnerability monitoring), SI (flaw remediation), AU (audit and accountability) — are also, not coincidentally, the ones that show up in the root-cause section of breach reports. Compliance is a lagging indicator of hygiene. Done right, it is also the forcing function that produces it.

What it is not worth. It is not worth building High-baseline controls for a commercial SaaS product with no federal pipeline. Over-scoping 800-53 is one of the most expensive mistakes I see, and I’ll come back to it at the end.

Part 2 — How often should it be audited?

There is no single answer, because “audited” collapses four different activities that run on four different clocks. Getting this straight is most of the discipline.

Activity	Who	Cadence	Authority
Vulnerability scanning (OS, web app, DB)	Internal	Monthly minimum; weekly for databases under FedRAMP	RA-5, SI-2
POA&M review and update	Internal	Monthly	CA-5
Ongoing control assessment (rolling subset)	Internal / ISSO	Continuous or quarterly	CA-7
Contingency plan test	Internal	Annual minimum	CP-4
Security awareness and role-based training	Internal	Annual	AT-2, AT-3
Penetration test	Independent	Annual for Moderate and above	CA-8
Full control assessment	Independent assessor / 3PAO	Annual under FedRAMP; otherwise at reauthorization	CA-2
Reauthorization	Authorizing Official	Every 3 years, or continuous authorization	RMF Step 6

Two things about assessor independence, because this is where organizations get caught:

Low-impact systems may self-assess.
Moderate-impact systems require an assessor independent of the implementation team — a different team inside your organization can qualify.
High-impact and FedRAMP systems require an accredited third-party assessment organization.

My practical recommendation for a private company with no federal mandate: run a full internal control assessment annually against your tailored baseline, an independent external assessment every two years, monthly scanning and POA&M discipline without exception, and a rolling quarterly assessment of roughly one quarter of your control set so that every control gets touched inside twelve months. That last item is the one nobody does, and it’s the one that makes the annual assessment boring instead of terrifying.

The direction of travel matters here too. The federal program is actively moving off point-in-time assessment. FedRAMP announced its 20x modernization in March 2025 and has been building toward continuous, machine-readable evidence, Key Security Indicators, and automated validation in place of annual assessment plus monthly manual deliverables. FedRAMP published Consolidated Rules in June 2026, and legal analysts read those rules as transitioning existing Rev5 authorizations toward 20x with Rev5 status expected to end by 2028. Whatever the exact timeline turns out to be, the design intent is unambiguous: demonstrate the control working, don’t describe it. If your evidence is a human taking a screenshot, you are building technical debt.

Part 3 — The continuous compliance operating model

Here is how to actually run it.

1. Treat your control set as data, not as a document

The Word-document SSP is the single biggest structural cause of drift. A 400-page narrative cannot be diffed, tested, or queried, so it decays silently.

Move your control inventory into a structured form: one record per control, with implementation status, responsible role, inherited-vs-system-specific designation, the organization-defined values you assert, the evidence source, and the collection frequency. OSCAL is the NIST-developed format for exactly this — catalog, profile, component definition, SSP, assessment plan, assessment results, and POA&M all have machine-readable representations. Even if you never submit OSCAL to anyone, modeling your program that way means you can ask questions like “which controls have no automated evidence source?” and get an answer in seconds.

Rule of thumb: if you cannot generate your SSP from your control data, you have a document, not a program.

2. Instrument the controls that actually drift

Not all 323 Moderate controls decay at the same rate. Physical controls (PE) barely move. Policy controls (the -1 control in every family) move annually. The controls that break between audits are a predictable short list, and they deserve automated telemetry:

Control	What drifts	Automate
AC-2, AC-2(3)	Orphaned accounts, stale privileges, inactive accounts past ODV	Daily IdP query against HR system of record
AC-6(7)	Privilege creep after project-based grants	Quarterly automated privileged-access review
CM-6	Configuration baseline deviation	Continuous config scanning (SCAP/XCCDF, CSPM, policy-as-code)
CM-8	Asset inventory divergence	Continuous discovery reconciled against CMDB
CM-3	Undocumented changes	Change records generated from the deployment pipeline
RA-5 / SI-2	Unpatched findings aging past ODV	Scanner-to-ticket integration with SLA clocks
IA-5(1)	Authenticator policy exceptions	Policy-as-code assertion in the IdP
AU-6	Logs collected but never reviewed	Detection content plus documented review cadence
CP-9	Backups running but never restore-tested	Scheduled automated restore verification

Everything else can run on a documented periodic review. Focus the engineering effort where the decay rate is highest.

3. Build evidence pipelines, not evidence hunts

Grade your evidence honestly. There are three tiers:

Machine-generated telemetry from the authoritative source. The IdP’s own account export. The scanner’s own output. Can’t be fabricated, can’t go stale.
Automated validation results. A policy-as-code check that asserts the control condition and emits pass/fail on a schedule.
Human-produced artifacts. Screenshots, meeting minutes, attestations.

Tier 3 is the tax you pay for every control you failed to instrument. Inventory your controls by evidence tier, then work the list. The goal is not perfection — it’s that the ratio moves in the right direction every quarter, and that no high-risk control depends on somebody remembering to take a screenshot in the week before the assessor arrives.

4. Convert your ODVs into service-level objectives

Organization-defined values (ODV) are the sharpest tool in the catalog and the most commonly wasted. When you write “disable inactive accounts after 90 days” into your SSP, you have just written an SLO. Treat it like one: instrument it, dashboard it, alert on breach, and report the metric — not the intention.

Control	ODV you assert	The metric that proves it
AC-2(3)	Inactive accounts disabled within 90 days	Max account inactivity age, measured daily
SI-2	Critical flaws remediated within 30 days	Age distribution of open critical findings
AU-11	Audit records retained 3 years	Oldest retrievable record, verified quarterly
CA-7	ConMon assessment frequency: monthly	% of scheduled assessments completed on time
IR-6	Incident reported within [x] hours	Median detection-to-report time per incident

Two failure modes to avoid. First, do not assert an ODV you cannot measure — assessors test exactly these values, and a missed ODV converts a satisfied control into an Other Than Satisfied finding. Second, do not set ODVs tighter than your operational reality to look good on paper. A 15-day critical patch ODV you breach every month is materially worse than a 30-day ODV you consistently hold.

5. Make change management the compliance trigger

Continuous compliance is really change control with a security-authorization boundary drawn around it. Every meaningful change to the system is a potential control-impact event, and CM-3 is where you catch it.

Wire a security-impact assessment into your change process. Three questions, answerable in a pull-request template:

Does this change the authorization boundary or introduce a new external interface?
Does this change how data is stored, transmitted, or classified?
Does this alter the implementation of any control in the SSP?

Any “yes” routes to the ISSO or security owner, updates the affected control narrative, and — for significant changes — triggers reassessment of the affected controls before deployment rather than at the next annual cycle. A “significant change” that reaches the assessor before it reaches you is the worst possible sequencing.

6. Run the POA&M as an operational queue

The POA&M (CA-5) is either a live remediation backlog or a document you write to make an auditor go away. Make it the former:

Every open item has a named owner and a real, defensible completion date
Risk-based deadlines with a working clock — the FedRAMP model is a reasonable default: 30 days critical, 90 days high, 180 days moderate, one year low
Monthly review with the same seriousness as a sprint review
Risk acceptance is a documented decision with business justification and signature from the system owner, not a status you drift into
Nothing sits in “risk accepted” indefinitely at high or critical severity

If your POA&M has items older than a year with no milestone movement, that is the finding. The underlying weakness is secondary.

7. Report metrics that predict the audit outcome

Board and executive reporting should not be a control count. Five numbers tell you whether the program is actually continuous:

Evidence automation ratio — % of controls with Tier 1 or Tier 2 evidence
ODV breach rate — % of asserted values held over the last 90 days
POA&M aging — count and oldest age of items past their scheduled completion date
Assessment coverage — % of the control set assessed within the last 12 months
Mean time to control restoration — how long a drifted control stays drifted once detected

If those five are healthy, the annual assessment is a formality. If they aren’t, no amount of documentation effort in assessment month will save you.

Part 4 — The twelve-month operating calendar

Cadence	Activities
Continuous	Config drift detection (CM-6), asset discovery (CM-8), account reconciliation (AC-2), log monitoring (AU-6, SI-4), automated control validation
Monthly	Vulnerability scans across OS / web / database (RA-5), POA&M update and review (CA-5), rolling control assessment slice (CA-7), security status report to the authorizing role
Quarterly	Privileged access review (AC-2, AC-6), risk register review (RA-3), supplier and supply-chain review (SR family), tabletop on one incident scenario (IR-3), backup restore verification (CP-9)
Annual	Full internal control assessment (CA-2), penetration test (CA-8), contingency plan test (CP-4), security awareness and role-based training (AT-2, AT-3), policy refresh across all -1 controls, privacy review (PT family), ODV re-validation
Every 3 years	Reauthorization / full independent assessment — or nothing at all, if you’ve achieved genuine ongoing authorization

Part 5 — Where this goes wrong

Five failure modes account for most of what I see:

Compliance owned entirely by GRC. If engineering doesn’t own control implementation, controls exist in documents only. GRC should own the framework, the evidence model, and the reporting. Engineering owns the controls.
Inherited controls assumed rather than verified. Your cloud provider covers a large slice of PE, MA, and parts of SC — but the customer-responsibility side of every shared control is yours, and it’s where assessors concentrate. Read the responsibility matrix; don’t assume it.
Tailoring never documented. Removing a control is legitimate. Removing it without a written scoping rationale is a finding, and a fast one.
PT and SR treated as optional. Privacy controls apply to any system processing PII regardless of impact level, and supply chain risk management was added as a full family in Rev 5. Both are still routinely skipped in programs built on Rev 4 muscle memory.
Screenshot-driven assessment prep. If the four weeks before an assessment look different from any other four weeks, the program isn’t continuous. That gap is exactly what the federal program’s shift to automated, machine-readable evidence is designed to eliminate.

My perspective: one catalog, two assurance markets

Here’s the view I’d argue for.

Stop thinking of NIST 800-53 as a federal framework you either need or don’t. It is the most complete security and privacy control catalog in public circulation, and it is free. Treat it as your internal control spine — the canonical statement of what your organization does about security — and treat every external framework as a rendering of that spine for a specific audience.

That reframing lets you stratify cleanly:

The private-sector expression is ISO 27001 and SOC 2. Both are audience-facing assurance products. Neither is as complete as 800-53, and both are heavily covered by an 800-53 Moderate implementation. If your market is commercial, do not chase federal-grade documentation artifacts. Implement against the Moderate baseline as an internal standard, tailor aggressively, and render your evidence into ISO Annex A and Trust Services Criteria formats. You will pass both audits with material effort savings, and you will have a substantially better security program than a SOC 2 report alone would produce.

The public-sector expression is FedRAMP, CMMC, and agency ATOs. This layer adds cost that has little to do with security and a lot to do with assurance formality: mandated ODVs, FIPS-validated cryptography, prescribed document templates, accredited third-party assessors, machine-readable submission formats, and a named official accepting risk on the government’s behalf. It is worth paying for only if there is a real federal revenue thesis behind it.

The strategic decision, then, is not “which framework.” It’s how high up the assurance ladder you climb, and when. My recommended sequencing:

Adopt the Moderate baseline as internal policy now, regardless of market. It costs nothing to use as your control taxonomy, and it means every future framework is a mapping exercise rather than a program build.
Automate evidence before you pursue certification. The organizations that struggle with FedRAMP are not the ones with weak controls — they’re the ones with strong controls and manual evidence. That constraint is getting sharper, not looser, as the program moves toward continuous machine-readable validation.
Climb to the public-sector tier only against a named opportunity. A specific agency, a specific prime, a specific contract vehicle. “Federal might be interesting someday” is not a business case for a 3PAO engagement.
Never run two programs. One control inventory. One evidence pipeline. Multiple renderings. The moment you have a FedRAMP evidence set and a separate SOC 2 evidence set, you’ve doubled your cost and halved your accuracy.

The organizations that get this right end up in an unusual position: continuous compliance stops being an expense line and becomes a sales asset. They answer security questionnaires in days instead of weeks, they enter federal procurement with the hard part already done, and their annual assessment is a review of numbers they were already watching.

That’s the whole objective. Not passing the audit — making the audit uninteresting.

HD “Disc” is Principal Consultant at DISC InfoSec, specializing in AI governance and information security compliance — ISO 42001, ISO 27001, NIST 800-53, and SOC 2 — for B2B SaaS and financial services organizations.

Working out where your organization sits on the assurance ladder, or trying to move an 800-53 program from annual scramble to continuous operation? Book a conversation. or email at info@deurainfosec.com

Sources: NIST SP 800-53 Rev 5, SP 800-53A Rev 5, SP 800-53B, SP 800-37 Rev 2, SP 800-137, FIPS 199/200. FedRAMP modernization details current as of July 2026 — verify against fedramp.gov before relying on specific dates.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

MachineLearning & Artificial Intelligence

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

DISC InfoSec blog | DISC InfoSec Site | Contact us at info@deurainfosec.com

Tags: NIST 800-53, NIST-800-53

BOOK A 20-MINUTE SCOPING CALL →

Jul 22 2026

AI Governance Readiness Assessment — Service

Category: AI Governance — disc7 @ 2:03 pm

A fixed-scope, fixed-fee, two-week engagement that tells a company exactly where it stands against an AI governance standard — and hands them a prioritized, costed remediation plan they can execute against.

Auditor-grade certainty in two weeks, not a six-month program.

Included

Kickoff + context intake (60 min) — business model, where AI touches the product, the deadline driving this
AI system inventory — a complete catalogue of where AI/ML operates across the product and vendors. Most teams cannot produce this, and every framework starts here.
Control-by-control gap analysis against one chosen framework (see lenses below)
Risk & impact assessment review — is there a defensible, repeatable process, or a one-off spreadsheet?
Evidence review — spot-check that priority controls actually operate and produce proof, not just exist on paper
Prioritized remediation roadmap — findings ranked by risk × effort, sequenced, with rough effort/cost estimates
Readout call (60 min) walking through the report and the recommended sequence

Explicitly excluded (these are the follow-on engagement)

Writing policies, procedures, or the Statement of Applicability
Running the risk or impact assessments on their behalf
Implementing or remediating any control
The certification audit or acting as certification body
Penetration testing or technical security testing of the AI system (separate offer)
More than one framework lens (multi-framework is a priced add-on)
Revisions beyond one round of clarifications on the final report

Framework lenses (pick one)

Lens	Best fit
ISO 42001	Flagship. Teams pursuing certification or building a formal AIMS. Your strongest proof point.
EU AI Act	Anyone with EU users or customers; deadline-driven urgency
NIST AI RMF	US teams wanting a framework without a certification commitment
Colorado AI Act / US state	US SaaS with consumer-facing AI decisions

Add-on: a second lens or an ISO 42001 ↔ EU AI Act crosswalk, priced at +50% of the base fee. This is a natural upsell for anyone serving both markets.

DISC InfoSec DEURA INFORMATION SECURITY CONSULTING

PAID READINESS ENGAGEMENT

AI Governance

Readiness Assessment

Know exactly where you stand — in two weeks, for a fixed fee.

Your free assessment gave you a directional score. This gives you the auditor’s-eye version: a control-by-control review of your actual AI governance against ISO 42001, the EU AI Act, NIST AI RMF, or US state law — and a prioritized, costed plan to close the gaps.

WHAT YOU GET

→ A complete inventory of where AI operates across your product	→ A gap register mapped to every relevant control, with maturity ratings
→ A remediation roadmap, sequenced by risk and effort, with cost estimates	→ A 60-minute readout to walk through it, personally

FIXED FEE / TWO WEEKS

CREDITED IN FULL TOWARD IMPLEMENTATION

IF YOU PROCEED WITHIN 90 DAYS

Led by DISC InfoSec — CISSP, CISM, ISO 42001 Lead Implementer — who took a financial data room platform through its ISO 42001 Stage 2 certification audit. Financial data rooms are the hard mode of compliance; if it holds up there, it holds up for you.

Is it a fit? Built for B2B SaaS and fintech teams with AI in production and a deadline in sight. Not there yet? The free assessment is the better starting

deurainfosec.com | hd@deurainfosec.com

DISC-AI-Governance-Readiness-Assessment-1-1 pdf download Download

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Jul 21 2026

GRC Engineering: From Evidence Theater to Genuine Assurance

Category: GRC,Information Security — disc7 @ 11:14 am

GRC Engineering: From Evidence Theater to Genuine Assurance

Most GRC programs are quietly optimized for the wrong outcome. They are built to survive an audit, not to reduce risk. The busiest weeks on the calendar are the ones before an assessor arrives, and the measure of success is a clean opinion rather than a safer environment. That is the gap GRC engineering exists to close.

The shift is simple to state and hard to internalize: stop spending human effort proving controls work, and start spending it understanding whether they actually do.

The problem with evidence collection

Traditional GRC burns most of its energy on a single low-value activity — assembling evidence to satisfy an auditor. Someone pulls a screenshot of an access review, exports a config, snips a ticket, drops it in a folder, and labels it. Multiply that across dozens of controls and hundreds of systems, and you have a full-time job that produces no security whatsoever. It produces a record of security, sampled once, at a moment that may bear no resemblance to how the environment looks the other 364 days of the year.

The screenshot is not the control. It is a photograph of the control on its best behavior.

From evidence collection to genuine assurance

This is the heart of GRC engineering. Instead of humans manually gathering artifacts, you automate collection so it pulls directly from the source system — the IdP, the cloud provider, the ticketing tool, the code repository — continuously and programmatically. When you do that, three things change in ways that compound:

Assurance gets stronger. You are no longer inspecting one sampled snapshot and hoping it generalizes. You are checking the real thing, continuously, against the live state of the system. A control that passes in January and silently drifts in March gets caught in March, not at next year’s audit.

Policies start to reflect reality. When the people writing policy can see the actual environment — not a sanitized description of it — the gap between “what we say we do” and “what we do” narrows. Policy stops being aspirational fiction and starts describing an enforceable, observable state.

The GRC professional stops being a translator. So much of the traditional role is shuttling screenshots between engineering and auditors, acting as a human API between teams that do not speak the same language. Automate that, and the practitioner is freed to do the work that requires judgment: interpreting risk, advising on trade-offs, and pushing for changes that actually move the needle. The job upgrades from clerk to advisor.

GRC as an insights function

Here is the reframing that makes all of this strategic rather than merely efficient.

When your data is continuous and machine-readable, GRC stops being an audit-prep function and becomes an insights function. You can suddenly surface signals that leadership has never had access to before: trends across hundreds of systems, concentrations of risk that only appear when you aggregate, and — the most valuable of all — controls that look perfectly fine on paper but keep failing quietly in practice.

That last category is where real risk hides. A control marked “implemented” in the register but failing 8% of the time is invisible to a checklist and obvious to a data pipeline. Only continuous, queryable evidence exposes it.

And in this model, audit readiness stops being the goal. It becomes a byproduct. If you are continuously verifying the real state of your controls and can produce that history on demand, the audit is no longer an event you brace for — it is a report you export. You were ready the whole time, because you were never doing this for the audit in the first place.

Why this is the real shift

It is tempting to sell GRC engineering as an efficiency play — fewer manual hours, faster evidence collection, lower cost of compliance. All true, and all beside the point. The efficiency is the least interesting thing about it.

The interesting thing is that GRC engineering changes what the function is for. It moves the center of gravity from “can we pass” to “are we actually secure, and how do we know” — and it gives you the data to answer that second question with something better than a shrug and a folder of screenshots.

My perspective

Having built and audited management systems on both sides of this — the manual, screenshot-driven world and the automated one — I think the framing above is broadly on the right track, but there are two areas where it would benefit from closer scrutiny.

First: automation raises the stakes on your control design, it does not lower them. When evidence collection was manual, a badly designed control was merely tedious to prove. When it is automated and continuous, a badly designed control fails loudly, constantly, and in front of leadership. That is a feature, but teams underestimate the cultural readiness it demands. The first time a dashboard shows a control failing 12% of the time, someone will ask to “fix the dashboard.” The maturity of a GRC engineering program is measured by how the organization answers that request. Continuous assurance is only valuable if you are prepared to act on inconvenient truths, not explain them away.

Second: the hardest part is not the pipeline — it is deciding what “passing” actually means. Automating collection is a solved problem; the tooling is mature. The genuinely difficult, irreducibly human work is translating a control objective into a machine-checkable assertion that is neither so loose it is meaningless nor so strict it drowns you in false positives. “All production access is reviewed quarterly” is a policy. Turning it into a query that knows what production is, what access counts, what a valid review looks like, and what to do about the service account that legitimately never gets reviewed — that is engineering judgment, and it does not automate away. It is exactly the work that gets freed up when you stop shuttling screenshots. So the promise of the advisor role is real, but only if the practitioner has the technical fluency to define the assertions in the first place. The role does not just get more strategic; it gets more technical. Both things are true at once, and the people who thrive in this discipline will be the ones comfortable living in that overlap.

The organizations I have seen get real value from this are, unsurprisingly, the ones operating in high-stakes data environments — where a control drifting silently for a quarter is not an audit finding, it is an incident waiting to be disclosed. When the downside is that severe, continuous assurance stops being a nice-to-have and starts being the only honest way to run the program.

GRC engineering, done well, is not compliance done faster. It is the point at which the compliance function finally starts telling the truth in real time.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: GRC Engineering

Jul 20 2026

AI Risk Management: AIRM isn’t a Security Problem — It’s Bigger

Category: AI,AI Risk,Risk Assessment — disc7 @ 9:23 am

AI Risk Management: The Discipline Your AI Strategy is Missing

Most organizations discovered last year just how much AI they were already running. A customer support chatbot here. Copilot in the IDE. Einstein scoring leads in the CRM. A fraud model someone built in 2021 that nobody owns anymore. When I run AI inventories for clients, the number of AI systems they think they have and the number they actually have are never the same — and the gap is where the risk lives.

That gap is exactly what AI risk management exists to close.

What Is AI Risk Management?

AI risk management is the discipline of identifying, evaluating, and treating the risks that AI systems introduce across their entire lifecycle — not just the security risks, but the fairness, robustness, transparency, privacy, and accountability risks that traditional security programs were never designed to catch.

Here’s the distinction that matters: prompt injection and jailbreaks are the security slice of AI risk. They get the headlines. But the risks that actually put organizations in front of regulators look different. A hiring model that screens out candidates from a protected class. A credit model that’s 95% accurate overall but 60% accurate on the demographic it impacts most. A production LLM that hallucinates a policy your company never had — to a customer, in writing. A model that drifted quietly for eighteen months because nobody was watching, and no one could explain its decisions when a regulator asked.

None of those are breaches. All of them are business-ending risks in the wrong context.

The most widely adopted framework for managing this is the NIST AI Risk Management Framework (AI RMF 1.0). It’s voluntary, but it has become the lingua franca of AI risk — cited in contracts, RFPs, executive orders, and increasingly in customer security questionnaires. If you speak NIST CSF, the shape will feel familiar. The AI RMF organizes the work into four functions:

GOVERN is the persistent layer: written AI principles, a named AI risk owner, approval gates for high-impact deployments, and — critically — someone with the authority to stop a deployment. If nobody in your organization can say “no” to an AI system, you don’t have governance. You have hope.

MAP establishes context per system: what does this AI actually do, who does it affect, what does “broken” look like, and — the question I find most clarifying in practice — is the decision reversible? A spam filter making a wrong call is an annoyance. A mortgage denial is not.

MEASURE is where the engineering happens: accuracy evaluated on data slices rather than aggregates, fairness metrics (demographic parity, equalized odds, calibration — which conflict, and choosing among them is a governance decision, not a technical one), robustness against adversarial inputs and distribution shift, and explainability. A model you cannot explain is a model you cannot defend in a regulatory inquiry.

MANAGE treats what MEASURE surfaces: retrieval-augmented generation for hallucination, monitoring and scheduled retraining for drift, human-in-the-loop for high-stakes decisions, vendor risk reviews for third-party models — and a decommissioning plan for every model, because an unowned production model is the AI equivalent of an unmaintained dependency.

Layer the regulatory landscape on top — the EU AI Act with its risk tiers and phased enforcement, the Colorado AI Act, NYC’s bias audit law for automated hiring tools, FTC and EEOC enforcement authority — and the picture is clear: AI risk management is no longer optional for any organization deploying AI in consequential decisions.

My Perspective: What a Proper AI Risk Management Program Actually Buys You

I led the ISO 42001 AI Management System implementation at ShareVault, a virtual data room platform serving M&A and financial services clients — an environment where the data is deal-sensitive and the tolerance for AI failure is effectively zero. Taking that program through a successful Stage 2 audit taught me what separates AI risk management as a paper exercise from AI risk management as a working system. Here’s what a proper program delivers:

It converts unknown risk into managed risk. The inventory step alone is worth the engagement. You cannot govern what you haven’t cataloged, and shadow AI — the tools employees adopted without review — is present in every organization I’ve assessed. Visibility precedes control, always.

It prevents the expensive failures, not just the embarrassing ones. Biased outcomes in hiring or credit carry regulatory penalties, litigation exposure, and remediation costs that dwarf the price of evaluating the model before deployment. Fairness testing during MEASURE costs days. A disparate-impact claim costs years.

It turns compliance from a scramble into a byproduct. Organizations with a working AI RMF-aligned program aren’t rebuilding from scratch when the EU AI Act’s high-risk requirements apply to them, or when a state law lands, or when an enterprise customer’s due-diligence questionnaire asks how they govern AI. The documentation, the impact assessments, the human oversight mechanisms — they already exist. Frameworks like NIST AI RMF and ISO 42001 map cleanly onto each other and onto the regulations. Build once, answer everywhere.

It becomes a sales asset. This is the part most organizations underestimate. In B2B — especially financial services — your customers’ risk teams are now asking about your AI. Being able to hand over an AI system inventory, model documentation, and evidence of independent audit doesn’t just pass procurement. It shortens sales cycles. At ShareVault, ISO 42001 certification became a differentiator precisely because the market is full of AI claims and short on AI evidence.

It lets you move faster, not slower. The counterintuitive one. Teams without governance hesitate on every AI deployment because nobody knows what’s acceptable. Teams with clear approval gates — rigorous review for high-impact systems, lightweight paths for low-impact ones — ship with confidence. Good governance is a throttle, not a brake. Overengineering the process kills it; right-sizing it accelerates everything.

The organizations getting AI risk management right in 2026 aren’t the ones with the thickest policy binders. They’re the ones who treated it as an operating discipline: inventory what you have, understand what it affects, measure what matters, treat what you find, and build the governance layer that keeps it working after the consultants leave.

Leadership must treat regulatory security, privacy & AI compliance as a strategic risk management priority. Noncompliance can lead to financial penalties, litigation exposure, reputational damage, and loss of customer trust. Top management should ensure that security, privacy & AI compliance risks are incorporated into enterprise risk assessments, evaluated using risk-based decision-making frameworks, reported regularly to executive leadership and governing bodies, and addressed through mitigation strategies aligned with organizational risk tolerance.

The ones getting it wrong will find out the way organizations always find out — in production, in public, or in front of a regulator.

HD is Principal Consultant at DISC InfoSec, a boutique cybersecurity and AI governance consultancy. He holds CISSP, CISM, AICP, ISO 27001 Lead Implementer, and ISO 42001 credentials, and led the ISO 42001 AIMS implementation and internal audit at ShareVault through a successful Stage 2 certification audit.

If your organization is deploying AI and can’t yet answer “how do you govern it?” — let’s talk. Book a consultation: info@deurainfosec.com

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

The-Balance-Sheet-Adversary_-Lazarus-Group-TTPs-Mapped-for-Defenders-—-DISC-InfoSec-1 Download pdf

Jul 12 2026

The adversary that treats your balance sheet as the objective

Category: Attack Matrix,Cyber Threats,Information Security,Threat detection,Threat Modeling — disc7 @ 4:02 pm

Download html file

lazarus-group-ttps-blog-Download html

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: Lazarus Group, TTPS

Jul 10 2026

Why Supplier Security Is Under the Spotlight — and How to Build a Vendor Management Program for the AI Era

Category: AI,AI Risk,Vendor Assessment — disc7 @ 7:22 am

Why Supplier Security Is Under the Spotlight — and How to Build a Vendor Management Program for the AI Era

Your security program is only as strong as the weakest vendor with access to your environment. That’s not a slogan anymore — it’s what the breach data says, it’s what regulators are writing into law, and it’s what enterprise buyers are now testing before they sign anything.

The numbers stopped being deniable

For years, third-party risk was something organizations acknowledged in a policy document and revisited once a year with a questionnaire. That era is over, and the data explains why.

SecurityScorecard’s 2025 Global Third-Party Breach Report attributes roughly 35% of all breaches to third parties. Other industry research puts supply chain breach exposure near-universal — the overwhelming majority of organizations experienced some form of supply chain security incident in 2025. Meanwhile, fewer than half of organizations monitor even 50% of their supply chain. And on the regulatory side, an estimated three-quarters of GDPR fines have a third-party component.

Read those together and the picture is simple: attackers have figured out that the vendor is the door, most organizations aren’t watching the door, and regulators are fining the building owner anyway.

Attackers didn’t get smarter about your perimeter. They got smarter about economics. Why spend months trying to breach one hardened enterprise when you can compromise one widely-used tool and inherit access to thousands of downstream environments at once?

The AI supply chain made it worse

The recent Trivy and LiteLLM supply chain attacks are the clearest example of where this is heading. These weren’t obscure utilities — they were trusted security and AI tooling sitting inside CI/CD pipelines. Attackers compromised the tools upstream, and the malicious code did exactly what you’d fear: harvested secrets, cloud credentials, and SSH keys from inside trusted processes, then used that access to move downstream into additional systems. Almost no warning signs, because the attack ran inside software everyone had already decided to trust.

The lesson isn’t “stop using open source” or “stop using AI tooling.” The lesson is that trust without verification is now a documented attack vector, and the AI era multiplies it in three specific ways:

First, AI tools proliferate faster than procurement can see them. Every SaaS product your vendors use is quietly adding AI features. Your data processor is now also an AI deployer, whether their contract with you contemplated that or not. Shadow AI in your supply chain is shadow AI in your risk register — you just haven’t written it down yet.

Second, AI dependencies are deep and opaque. When a vendor says “we use AI,” the real question is: whose model, trained on what, hosted where, with what access to your data, and what happens when the model provider changes terms, deprecates a version, or gets compromised? Fourth-party AI risk is real, and most vendor questionnaires never touch it.

Third, regulation now assigns you obligations for AI you didn’t build. Under the EU AI Act, if your organization uses a high-risk AI system, Article 26 puts deployer obligations directly on you — following instructions for use, ensuring human oversight and staff competence, monitoring operation, retaining logs, and reporting serious incidents. The AI Omnibus agreed in May 2026 pushed the Annex III high-risk deadline to December 2027, which is breathing room, not a reprieve. NIS 2 and DORA are applying the same logic to supply chain security generally: you are accountable for what your vendors do.

What buyers are actually testing in 2026

If you sell into enterprises or regulated industries, you’ve already felt this from the other side. Buyer expectations have shifted from trust to verification, and the deal breakers are consistent: no recent penetration test results, missing security fundamentals, no ISO 27001 or equivalent certification, slow or incomplete responses to security questionnaires, and misalignment with the regulatory frameworks the buyer answers to.

Certifications get you in the door. Evidence wins the deal. The vendors closing enterprise contracts fastest are the ones who lead with proof — current pen test reports, accredited certification rather than “aligned with,” and documentation that’s ready to share the day the security review lands. Supplier security has become a revenue function, not just a risk function. That’s the same lens you should apply when you’re the buyer.

Building a vendor management program for the AI era

A modern program has to handle two things the traditional model didn’t: continuous change and AI-specific risk. Here’s the build sequence I use with clients.

1. Inventory everything — including the AI. You can’t govern what you haven’t cataloged. Build a vendor register that captures not just who the vendor is and what data they touch, but whether they use or embed AI in delivering the service, whose models sit underneath, and what your data’s role is in those systems. ISO 42001 makes this concrete: the AI system register under Clause 4 should include third-party AI, not just what you built in-house. Most organizations I audit miss the SaaS-embedded AI entirely.

2. Tier by real risk, not spend. Classify vendors by data sensitivity, access level, operational criticality, and — new for this era — AI impact. A vendor whose AI feature makes or influences decisions about your customers or employees belongs in a higher tier than their invoice size suggests. This is where ISO 42001’s impact assessment thinking (the AISIA) earns its keep: intended purpose, affected population, severity, reversibility, human oversight. Apply that lens to vendor AI, not just your own.

3. Move due diligence from questionnaire to evidence. Stop accepting “yes” as an answer. For your critical tier, require the same things enterprise buyers now require of you: current certifications (ISO 27001, and increasingly ISO 42001 for AI-heavy vendors), recent independent testing, SOC 2 reports, and for AI vendors specifically — model documentation, data handling terms, and incident notification commitments. Under ISO 27001:2022, controls A.5.19 through A.5.22 cover the supplier relationship lifecycle; under ISO 42001, control A.10.3 requires assessing suppliers of AI systems and services. If your vendor security policy hasn’t been updated to reference AI suppliers, it’s a 2022 policy living in a 2026 threat landscape.

4. Put obligations in the contract, not the questionnaire. Questionnaire answers expire the day they’re submitted. Contracts persist. Bake in security requirements, breach and AI-incident notification timelines, audit rights, subprocessor transparency (this is where fourth-party AI risk gets managed), and for EU-relevant AI, allocation of provider and deployer responsibilities under the AI Act. When the regulator asks who was responsible, “we assumed the vendor handled it” is not an answer.

5. Monitor continuously, not annually. The Trivy and LiteLLM attacks would not have been caught by an annual review cycle. Continuous assurance means external attack surface monitoring on critical vendors, tracking certificate status and expirations, watching for vendor breach disclosures, and — for AI suppliers — monitoring for model changes, terms-of-service changes, and deprecations that alter your risk position. This is exactly the shift regulators are codifying: DORA and NIS 2 both expect ongoing oversight, not point-in-time attestation.

6. Plan for vendor failure, because it will happen. Have an exit and containment plan for your critical vendors before you need one. Know how to revoke access fast, what data comes back and how, and what the operational fallback is. Incident response plans that don’t include supply-chain scenarios are incomplete — and ISO 42001’s incident management controls (A.8.4) expect AI-specific scenarios, including incidents originating in third-party models.

My perspective

After two decades of implementing and auditing security programs — most recently taking an AI-forward SaaS platform through ISO 42001 Stage 2 certification — here’s what I’ve come to believe about vendor management.

Most vendor risk programs are theater. A 300-question spreadsheet, answered optimistically by a vendor’s sales engineer, filed in a folder nobody reopens until renewal. That model was weak before AI; it’s indefensible now. The organizations getting this right have made one mental shift: they treat their vendors as an extension of their own attack surface and their own regulatory perimeter, because functionally, that’s what vendors are. The breach data proves it, and the EU AI Act’s deployer obligations make it legally explicit.

The second shift is recognizing that vendor security has flipped from a cost center to a commercial differentiator — in both directions. Run a rigorous program and you avoid becoming the 35%. Maintain rigorous, shareable evidence of your own posture and you close enterprise deals your competitors stall on. The same investment pays twice.

And the third: don’t wait for the AI-specific regulation to fully land before governing AI in your supply chain. The December 2027 high-risk deadline feels distant. It isn’t — not when your remediation path runs through contract renegotiations, vendor replacements, and evidence collection that takes quarters, not weeks. The organizations that treated GDPR as a 2018 problem in 2017 spent that year in triage. The ones building AI vendor governance now, on an ISO 42001 backbone that already integrates with their ISO 27001 ISMS, will spend 2027 selling trust while everyone else is buying consultants in a panic.

Your supply chain already has AI in it. The only question is whether your vendor management program knows that yet.

DISC InfoSec helps B2B SaaS and financial services firms build ISO 27001 and ISO 42001 programs that stand up to enterprise scrutiny and regulatory audit. If you want a straight answer on where your vendor management program stands, book a call: calendly.com/hd-deurainfosec.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: Vendor Management

Jul 09 2026

GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined

Category: GDPR — disc7 @ 10:44 am

GDPR Isn’t a Cookie Banner: The Audit Findings That Actually Get Companies Fined

Seven years after GDPR took effect, most organizations still treat it like a checkbox they ticked in 2018. They dropped in a cookie banner, published a privacy policy their own lawyers haven’t read since, and moved on. Then a data subject access request lands, or a breach hits, or a regulator comes knocking — and suddenly the gap between “we have a privacy policy” and “we can actually demonstrate compliance” becomes very, very expensive. The uncomfortable truth I keep running into in audits is that GDPR failures rarely look dramatic. They’re not master hackers exfiltrating databases. They’re mundane, systemic gaps that sat quietly in plain sight until the day they didn’t. And with AI now feeding on personal data for marketing, sales, and product decisions, the old gaps have gotten wider and the new ones are appearing faster than most compliance programs can track.

Here’s what I actually find when I open the hood — and, more importantly, how to fix it.

Finding #1: No Defensible Lawful Basis (Especially for AI)

What I find: Organizations collect personal data across forms, chat, analytics, and enrichment tools without a documented lawful basis for each processing activity. When AI enters the picture, this gets worse — data collected for support or account management quietly gets repurposed to train or run marketing models, with no fresh basis and no assessment. “Legitimate interest” is invoked as a magic phrase, but no Legitimate Interest Assessment (LIA) exists to back it up.

Why it matters: Lawful basis is the foundation of the entire regulation. Without it, every downstream activity is built on sand — and repurposing data for AI without a compatible basis is one of the fastest-growing enforcement themes in Europe.

How to remediate: Build a processing inventory that maps each data type to a specific lawful basis. Where you rely on legitimate interest, write the LIA — a genuine three-part balancing test, not a paragraph. For any AI use, treat it as its own processing activity: document the basis for feeding personal data into the model, and never assume that consent for one purpose covers another.

Finding #2: The Privacy Notice Doesn’t Match Reality

What I find: The privacy policy describes a company that stopped existing years ago. It doesn’t mention the AI tools now processing customer data, doesn’t name key processors, and says nothing about profiling or automated decision-making. It’s transparency theater — technically present, functionally useless.

Why it matters: Transparency is a legal obligation, not a courtesy. If you’re using AI to score, segment, or make decisions about people, they have a right to know — in plain language — what’s happening and what it means for them.

How to remediate: Rewrite the notice to reflect current reality. Disclose AI processing explicitly, describe what the AI does with personal data, name your processor categories, and clearly explain any profiling and its likely consequences. Then put a recurring review on the calendar — a privacy notice is a living document, not a monument.

Finding #3: Data Subject Rights Requests Can’t Reach the AI Layer

What I find: The company can pull a record from the CRM when someone files an access or erasure request — but has no idea how to locate that person’s data inside the AI system, its logs, or its training set. Worse, when someone objects to marketing or profiling, the objection updates a flag in one system while the AI keeps processing them unchanged.

Why it matters: Rights that stop at the CRM aren’t rights. “We can’t delete that from the model” is a finding, not an acceptable answer — and an objection that doesn’t actually stop processing is a live violation every day it persists.

How to remediate: Map where personal data flows across every system, including the AI layer and its logs. Build rights fulfillment that propagates: an objection or erasure request must reach — and take effect in — the AI system, not just the primary database. Where model training makes deletion technically hard, document your handling approach in advance rather than improvising under a 30-day clock.

Finding #4: Vendor Contracts and Transfers Left Unmanaged

What I find: Personal data flows to a stack of third parties — AI vendors, ad platforms, analytics, enrichment services — often without signed Article 28 Data Processing Agreements. The AI vendor’s terms are unread, meaning nobody actually knows whether the vendor is training its own models on the company’s data. And data routinely leaves the EEA (frequently via US-based AI providers) with no valid transfer mechanism and no Transfer Impact Assessment.

Why it matters: You remain accountable for personal data even after it leaves your systems. An unread AI vendor contract that permits training on your data can turn your customers’ information into someone else’s product — and undocumented international transfers are a well-established enforcement target.

How to remediate: Inventory every processor and sub-processor. Get signed DPAs in place, and read the AI vendor’s terms specifically for whether your data trains their models — get that prohibited in writing if it isn’t already. For any transfer outside the EEA, confirm a valid mechanism (SCCs or adequacy) and complete a Transfer Impact Assessment for high-risk vendors.

Finding #5: No DPIA for High-Risk Processing

What I find: The organization is doing exactly the kind of large-scale profiling and automated decision-making that makes a Data Protection Impact Assessment mandatory under Article 35 — and no DPIA exists. There’s also no Record of Processing Activities that includes the AI, so when a regulator asks the company to demonstrate compliance, there’s nothing to hand over.

Why it matters: GDPR runs on accountability. It’s not enough to be compliant; you have to be able to prove it. A missing DPIA on high-risk AI processing is both a violation in itself and a signal to any regulator that the deeper controls probably aren’t there either.

How to remediate: Run the DPIA before scaling the AI initiative, not after. Document the processing, the risks to individuals, and the mitigations — and consult your DPO. Update the Article 30 Record of Processing Activities to include the AI. These artifacts are the evidence that turns “we think we’re compliant” into “here’s the file.”

My Perspective

After enough of these audits, a pattern becomes impossible to ignore: GDPR compliance almost never fails on the technology. It fails on the paper trail and the follow-through. The encryption is usually fine. What’s missing is the documented lawful basis, the honest privacy notice, the rights process that actually reaches every system, and the evidence that ties it all together. GDPR is, at its core, an accountability regime — and accountability is exactly the muscle most organizations skipped building.

AI has raised the stakes considerably. The same discipline GDPR has demanded since 2018 — know your data, justify your processing, honor people’s rights, prove it — is now the same discipline that frameworks like ISO 42001 and the EU AI Act demand for AI systems. That’s not a coincidence; it’s convergence. The companies that treated GDPR as a genuine data-governance practice rather than a cookie banner are the ones now absorbing AI governance almost effortlessly. The ones that faked it in 2018 are discovering there’s nothing underneath to build on.

My advice is simple and unglamorous: stop auditing for the banner and start auditing for the evidence. Can you produce your lawful basis, your DPIA, your vendor DPAs, and your rights-fulfillment records on demand? If yes, you’re most of the way there. If not, that gap won’t announce itself — until the day a request, a breach, or a regulator forces it into the open. Fix it while it’s still your choice.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation & Feel free to contact DISC InfoSec for a GDPR assessment: info@deurainfosec.com

Tags: Audit Findings, gdpr

Jul 07 2026

ATT&CK vs. ATLAS: Why Securing AI Systems Needs Its Own Playbook

Category: Attack Matrix,Information Security — disc7 @ 1:04 pm

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is specifically about attacks on AI and machine learning systems — things like data poisoning, model evasion, model extraction, and prompt injection. It’s modeled on the ATT&CK structure (tactics and techniques) but applied to the AI/ML attack surface. The description in your source looks like it may have been confused with a generic threat-intel sharing platform.

This actually makes for a much stronger post for your audience — because the real distinction between ATT&CK and ATLAS sits right at the intersection of cybersecurity and AI governance, which is your whole positioning. Here’s the blog post built on the accurate framing:

ATT&CK vs. ATLAS: Why Securing AI Systems Needs Its Own Playbook

Every security leader knows MITRE ATT&CK. It’s the shared language we use to describe how adversaries move through our environments — the periodic table of attacker behavior. But fewer people have met its younger sibling, MITRE ATLAS, and that gap is becoming a liability. As organizations rush to deploy AI and machine learning into production, they’re discovering that the attack surface has quietly expanded into territory ATT&CK was never built to cover. If ATT&CK tells you how an adversary breaks into your network, ATLAS tells you how an adversary breaks your model. Understanding the difference isn’t academic — it’s the line between an AI governance program that looks good on paper and one that actually holds up when someone tries to poison your training data.

MITRE ATT&CK: The Map of Adversary Behavior

ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a globally adopted knowledge base of real-world attacker behavior. It’s organized around the lifecycle of an intrusion — the tactics an adversary uses and the specific techniques under each. The framework walks through the full arc of an attack: Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, and Command and Control.

Its power is that it gives defenders a shared vocabulary. Threat hunters use it to map suspicious activity to known techniques. Incident responders use it to anticipate an attacker’s next move. Red teams use it to structure engagements, and security architects use it to test whether their controls actually cover the techniques they claim to. When someone says “we detected T1566 phishing leading to T1055 process injection,” everyone in the room knows exactly what happened.

MITRE ATLAS: The Map of AI-Specific Threats

ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) borrows ATT&CK’s structure but points it at a different target entirely: machine learning and AI systems. It catalogs the tactics and techniques adversaries use to attack models rather than networks — and these threats behave nothing like traditional intrusions.

ATLAS covers techniques such as data poisoning (corrupting training data so the model learns the wrong things), model evasion (crafting inputs designed to fool a deployed model), model extraction or theft (reconstructing a proprietary model by probing its outputs), membership inference (determining whether specific data was in the training set), and — increasingly relevant in the LLM era — prompt injection and manipulation of generative systems. It’s grounded in real-world case studies of AI systems being attacked, not hypotheticals. Crucially, an attacker doesn’t need to breach your perimeter to exploit many of these; they can attack the model through its legitimate interface.

When to Reach for Each

The two aren’t competitors — they’re complementary layers of the same defensive posture.

Reach for ATT&CK when you’re defending infrastructure, endpoints, identities, and networks: threat hunting, incident response, control validation, and red team planning against conventional adversary behavior. It remains the backbone of any mature SOC.

Reach for ATLAS when AI or ML systems are part of what you’re protecting: threat modeling a model before deployment, assessing the AI-specific attack surface, red teaming a machine learning pipeline, or building an AI risk register. If your organization is deploying models that make or influence decisions, ATLAS is where the relevant threats actually live.

The Overlap Is Where It Gets Interesting

Here’s the nuance most people miss: real attacks on AI systems often chain both. An adversary might use classic ATT&CK techniques to gain access to your training environment, then pivot to ATLAS techniques to poison the data once inside. The perimeter breach is ATT&CK; the model corruption is ATLAS. A defense program that only speaks one language will see half the kill chain and miss the other half entirely. Mature organizations use ATT&CK and ATLAS together, mapping how a traditional intrusion can become the delivery mechanism for an AI-specific attack.

My Perspective

For years, “AI security” was treated as a subset of application security — protect the servers, secure the API, encrypt the data, and you’re covered. ATLAS exists because that assumption is dangerously incomplete. The model itself is now an attack surface, and it fails in ways firewalls and EDR were never designed to catch. A poisoned model can pass every traditional security check and still make catastrophic decisions in production.

This is exactly where cybersecurity and AI governance converge — and why frameworks like ISO 42001 and the NIST AI RMF increasingly point toward AI-specific threat modeling as a core control, not an afterthought. In my own work implementing AI Management Systems, ATLAS has become the natural bridge: it translates abstract AI risk into concrete, testable adversary techniques that a security team can actually assess and mitigate. My advice to security leaders is simple — don’t wait for an incident to discover this gap. If you have models in production and your threat modeling stops at ATT&CK, you have a blind spot the size of your entire AI footprint. Add ATLAS to the toolkit now, while your AI attack surface is still something you can get ahead of rather than something you’re cleaning up after.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: MITRE ATLAS, MITRE ATT&CK

Jul 03 2026

20 State Laws, One Enforcement Standard: Privacy by Design or Pay

Category: Information Privacy,ISO 27k — disc7 @ 10:19 am

Privacy Just Became Infrastructure. Most AI Programs Haven’t Noticed.

By DISC InfoSec

For twenty years, privacy compliance meant disclosure: post a policy, collect consent, answer the occasional access request. That era is over. In 2026, privacy is infrastructure — regulators are testing whether your controls actually work, not whether your privacy notice reads well.

I spend my days implementing management systems for companies where the data can’t leak — financial data rooms, M&A platforms, AI-enabled SaaS. Here’s what the privacy threat landscape actually looks like right now, and what I’d do about it.

In practical terms, it means:

Privacy is built into systems by design. Organizations must embed privacy controls into applications, AI systems, cloud platforms, and data architectures from the beginning rather than adding them later.
Privacy enables business operations. Just as networking, identity management, and cybersecurity are core infrastructure, privacy has become an essential capability that supports AI, data sharing, digital services, and regulatory compliance.
Privacy is a technical and operational discipline. Engineers, architects, security teams, and AI governance professionals are now responsible for implementing privacy-enhancing technologies, data minimization, consent management, encryption, and access controls—not just legal or compliance teams.

For organizations deploying AI, the phrase is especially relevant because regulations and frameworks increasingly require privacy to be integrated into AI governance. This includes conducting privacy impact assessments, limiting unnecessary data collection, protecting personal information, and ensuring transparency and accountability throughout the AI lifecycle.

In short, “Privacy Just Became Infrastructure” means privacy is now a foundational capability that organizations must engineer, manage, and continuously maintain—just like cybersecurity, identity, and cloud infrastructure.

The pressure on industry, in general

The patchwork is now a wall. Twenty US states have comprehensive privacy laws in force. Indiana, Kentucky, and Rhode Island went enforceable this year. California’s updated CCPA regulations now mandate independent cybersecurity audits with certifications filed to the CPPA, and formal risk assessments before any “significant risk” processing begins. Rhode Island carries no cure period — day-one enforcement exposure. If your compliance program was built for one or two state laws, it’s already behind. Compliance is no longer optional or fragmented. The growing number of regulations now creates a comprehensive set of expectations that every organization must address.

Enforcement moved from awareness to action. California imposed its largest CCPA fine to date in 2025, targeting exactly the unglamorous stuff: broken opt-out mechanisms, missing processor contract clauses, notices that don’t match actual processing. California, Colorado, and Connecticut ran a joint sweep on Global Privacy Control compliance. Regulators are no longer reading your policy — they’re testing your website.

The data you forgot about is the data that kills you. The average US breach now costs over $10M. In almost every incident I’ve reviewed, the most damaging records were the ones nobody knew the company still held. No current data inventory means no defensible position — full stop.

Cross-border transfers are a moving target. DOJ’s bulk data transfer rule, Vietnam’s new PDPL, evolving adequacy politics — transfer assessments are now a living exercise, not a one-time SCC signing ceremony.

The pressure in the AI space, specifically

AI didn’t create new privacy principles. It broke every assumption the old controls were built on.

Training data is now a regulated disclosure. California’s AB 2013 requires generative AI developers to publicly summarize the categories and sources of their training data. If you fine-tuned a model on customer data and can’t document what went in, you have a transparency problem with an enforcement hook.

Inference is processing. Every prompt containing customer PII, every RAG pipeline pulling from a CRM, every AI agent reading a mailbox — that’s personal data processing, with all the lawful-basis, minimization, and retention obligations that implies. Most AI inventories I review don’t capture inference-time data flows at all.

Automated decisions are the new high-risk zone. Colorado’s AI Act, Texas TRAIGA, and California’s ADMT regulations converge on the same target: AI making consequential decisions about employment, credit, housing, healthcare. The EU AI Act’s high-risk obligations land in August. If your AI touches a consequential decision and you can’t produce a risk assessment, you’re the test case.

Models remember. Memorization and output leakage mean personal data put into a model can come back out — to a different user, in a different context. “We deleted the source record” doesn’t answer “is it still in the weights?”

Shadow AI is shadow processing. Employees pasting customer data into consumer AI tools is the 2026 version of the rogue file share — except the data leaves your control permanently and may train someone else’s model.

Where ISO 27701:2025 changes the math

Here’s the development most compliance teams haven’t caught up with: ISO 27701 was rebuilt as a standalone standard in October 2025. You no longer need ISO 27001 first — you can implement and certify a Privacy Information Management System (PIMS) on its own, with 78 Annex A controls split across PII controller obligations (A.1), processor obligations (A.2), and shared security controls (A.3). The 2025 edition explicitly added control coverage for cloud, IoT, and AI processing — the standard caught up to the threat landscape.

It also shares the same harmonized structure as ISO 27001:2022 and ISO 42001:2023. That matters practically: if you’re building AI governance and privacy management at the same time — and in 2026, you are — the clause structures interlock. One risk methodology, one internal audit program, one management review. I’ve run that integration play; the overhead savings are real.

One honest caveat, because practitioner credibility requires it: ISO 27701 is not a GDPR safe harbor. Certification doesn’t shield you from enforcement and carries no legal presumption of compliance. What it does provide is the thing regulators actually ask for — demonstrable accountability: a current RoPA, tested data subject rights procedures, documented DPIAs, processor contracts with the right clauses, and evidence behind every control. When the CPPA or a DPA comes asking, “we have a certified, audited PIMS” is a very different conversation than “here’s our privacy policy.”

(Already certified under the 2019 edition? You have until October 2028 to transition. Start scoping now — the control structure changed materially.)

My perspective: the threat is unmanaged processing, not AI

The core privacy threat in 2026 isn’t any single technology. It’s processing that nobody owns, nobody inventoried, and nobody assessed — and AI multiplies the amount of it exponentially. Every remediation path runs through the same discipline:

1. Inventory first. Build a unified data + AI inventory: what personal data you hold, which AI systems touch it, at training and at inference. You cannot protect what you cannot see.

2. Assess before you deploy. DPIAs for every AI system processing personal data, mandatory for anything touching consequential decisions. The EU AI Act, Colorado, and California all converge here — one good assessment process serves all three.

3. Fix the processor chain. Audit your DPAs and sub-processor terms against actual data flows, including AI vendors. Contract gaps are the most-fined, least-fixed problem in privacy.

4. Operationalize rights. Data subject requests must work end-to-end — including data that went into AI systems. Test them like you’d test a DR plan.

5. Put it in a management system. Point-in-time compliance decays. A PIMS under ISO 27701:2025 forces the loop — risk assessment, treatment, internal audit, management review, corrective action — that keeps the program alive between audits.

Privacy by design used to be a slogan. In 2026 it’s the enforcement standard. The organizations that treat privacy as infrastructure will spend less, move faster, and sleep better than the ones still treating it as paperwork.

DISC (CISSP, CISM, ISO 27001 & ISO 42001 Lead Implementer) Consultant at DISC InfoSec, helping B2B SaaS and financial services firms build integrated security, privacy, and AI governance programs — including taking a financial data room platform through ISO 42001 certification. Financial data rooms are the hard mode of compliance; privacy programs built for hard mode work everywhere.

Building or transitioning a PIMS? Start the conversation: info@deurainfosec.com | deurainfosec.com

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: ISO 27701, PIMS

Jul 02 2026

Compliance Event vs. Compliance Capability: Why ISO 42001 is How You Actually Meet the EU AI Act

Category: ISO 42001 — disc7 @ 9:50 am

How they relate

The cleanest way to frame it: the EU AI Act defines outcomes; ISO 42001 supplies the machinery to produce them repeatedly. The Act (Regulation (EU) 2024/1689) is enforceable law with fines up to €35M or 7% of global turnover for prohibited practices. ISO 42001 is a voluntary, certifiable management system standard published December 2023. One can’t substitute for the other — an ISO 42001 certificate is not a legal safe harbor, and Act compliance without a management system is a snapshot that decays the moment your AI systems, vendors, or models change.

How they complement each other. The Act tells you a high-risk system needs a risk management system (Art. 9), data governance (Art. 10), technical documentation (Art. 11), logging (Art. 12), human oversight (Art. 14), and — critically — a full quality management system with 13 required components (Art. 17). It doesn’t tell you how to build, document, audit, or continually improve any of that. ISO 42001’s Clause 4–10 PDCA structure and 38 Annex A controls are exactly that operational layer: the AISIA process, the AI system register, the SoA, supplier assessments, internal audit, management review. The Act’s own cross-framework guidance recognizes that ISO 42001 certification can support demonstration of Art. 17 QMS compliance, and the SoA process adapts naturally into an AI Act conformity mapping.

How they depend on each other. The dependency is mostly one-directional. The Act doesn’t need ISO 42001 to exist — but a 42001 AIMS must ingest the Act. Clause 4 (context of the organisation) requires you to identify legal obligations as interested-party requirements, so for any organisation touching the EU market, the AI Act becomes a mandatory input to your AIMS scope, risk assessment, and SoA justifications. Practically: the Act feeds requirements into the AIMS; the AIMS feeds evidence back out for conformity assessment (Arts. 43–48), the EU Declaration of Conformity (Art. 47, retained 10 years), and post-market obligations.

Shared control mapping

EU AI Act	Requirement	ISO 42001	Shared control objective
Art. 9	Risk management system (lifecycle-spanning)	Clause 6.1.2 + A.5.2–A.5.5	Continuous AI risk + impact assessment (AISIA) informing control selection
Art. 10	Data governance, bias detection, representative datasets	A.7.2–A.7.6	Data lifecycle governance: acquisition, quality, provenance, preparation
Art. 11	Technical documentation (Annex IV)	A.6.2.3, A.6.2.7	Documented design decisions, specifications, limitations, failure modes
Art. 12	Record-keeping / automatic logging	A.6.2.8	Event logs sufficient for incident investigation and audit
Art. 13	Transparency + instructions for use to deployers	A.8.2, A.9.4	Intended-purpose documentation and user-facing system information
Art. 14	Human oversight (override, intervene, disregard)	A.9.2, A.6.1.3	Human review of AI outputs, escalation and override procedures
Art. 15	Accuracy, robustness, cybersecurity	A.6.2.4, A.6.2.6	Pre-deployment V&V (bias/adversarial testing) + production drift monitoring
Art. 17	Quality management system (13 components)	Clauses 4–10 (entire AIMS)	The management system itself — policy, roles, competence, audit, improvement
Art. 26	Deployer obligations (competence, monitoring, logs)	A.4.6, A.9.2–A.9.3	Staff competence, responsible-use processes, use monitoring
Art. 50	Transparency (chatbots, synthetic media)	A.8.5	Informing interested parties they’re interacting with AI
Art. 72	Post-market monitoring plan	Clause 9.1, A.6.2.6	Ongoing performance evaluation with defined thresholds
Art. 73	Serious incident reporting	A.8.4, Clause 10.2	Incident classification, escalation, regulatory notification, corrective action

Third-party AI in the supply chain is the one area the Act handles thinly relative to 42001 — A.10.2/A.10.3 (responsibility allocation, supplier due diligence with contractual AI clauses) go further than the Act’s provider/deployer split, and they’re what actually protects a deployer who inherits risk from a GPAI vendor.

Where to start

Start with three Act-driven steps that take days, not months, then build the 42001 system underneath:

Role and inventory first. Determine whether you’re a provider or deployer under Art. 3 (most companies are both), and build the AI system register — 42001’s most commonly missed artifact, and the input everything else depends on. Shadow AI and SaaS-embedded AI features count.
Prohibited-practices screen (Art. 5). The 8 original prohibitions have applied since February 2025, and the 9th (nudification/CSAM) lands 2 December 2026. This is the only tier carrying 7%-of-turnover exposure, so screen it before anything else.
Risk-tier classification (Art. 6). Sort your register into prohibited / high-risk / limited / minimal. This tells you how much of the mapping table above actually applies to you.
Then build the AIMS. With classification done, implement ISO 42001 as the delivery vehicle: scope (4.3), AI policy (5.2), AISIA and risk assessment (6.1.2), SoA — with each applicable Annex A control’s justification column citing the AI Act article it discharges. That single move turns your SoA into a living conformity map.

The AI Omnibus (May 2026) extended the Annex III high-risk deadline to 2 December 2027, which changes the calculus in one specific way: you now have time to do this via a management system rather than a panic project. GPAI obligations and Art. 50 transparency deadlines did not move, so those bite first.

My perspective

If I had to compress it: the EU AI Act is a compliance event; ISO 42001 is a compliance capability. Organizations that chase the Act article-by-article end up with a binder of point-in-time evidence that’s stale by the next model update. Organizations that build the AIMS first get Act conformity as a byproduct — plus reusable coverage for NIST AI RMF, Colorado’s AI Act, and whatever jurisdiction regulates next, because the artifacts (register, AISIA, SoA, supplier assessments, incident process) are framework-agnostic at their core.

The honest caveats: 42001 certification is not presumption of conformity — the Art. 40 harmonised standards that would grant that are still in development, and a certificate won’t save a provider whose system fails Art. 15 accuracy requirements in practice. And the Act is scoped to the EU market while 42001 is scoped to your organization, so a pure-42001 approach can under-invest in the Act’s market-facing mechanics: CE marking, EU database registration, the Declaration of Conformity.

So my recommendation is deliberately asymmetric: classify under the Act first (cheap, fast, identifies your real exposure), then invest the bulk of your effort in the 42001 AIMS, wiring every SoA justification to an Act article. The deadline extension to December 2027 is exactly enough runway to do it properly — a Stage 1/Stage 2 certification cycle typically runs 6–12 months, which means starting in 2026 gets you certified with a full surveillance cycle of operating evidence before enforcement begins. Waiting turns a management-system build into a fire drill.

If it’s useful, I can turn this into a blog post and hero image in the DISC brand system, or build out the full Act-to-Annex-A crosswalk as a downloadable gap-assessment worksheet.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: EU AI Act, ISO 42001

Jul 01 2026

The AI RMF Gap Nobody’s Talking About: Why GOVERN-Heavy Programs Still Fail Audits

Category: AI,AI Risk,Risk Assessment — disc7 @ 8:04 am

This is the AI RMF gap assessment, not the checklist version. Most write-ups treat GOVERN, MAP, MEASURE, and MANAGE as four boxes to tick. In practice, the interesting failure isn’t which box is empty — it’s the pattern across the boxes. That pattern is what tells you whether your AI program is actually managing risk or just documenting that it thought about risk once.

The trap: treating AI RMF like a checklist

NIST AI RMF 1.0 is voluntary and non-prescriptive by design. That flexibility is the point — it’s supposed to flex to your context, your risk tolerance, your regulatory exposure. But voluntary frameworks have a predictable failure mode: organizations write the GOVERN policy, feel the box getting checked, and stop.

Nineteen categories across four functions look like a checklist. They’re not. They’re a chain. And chains break at the weakest link, not the first one.

The four functions, in the order risk actually moves through them

Function	What it does	The practitioner question
GOVERN	Sets accountability, roles, and risk tolerance — underpins everything else	Who actually owns this when it breaks?
MAP	Establishes context before a system ships — intended use, stakeholders, foreseeable misuse	What did we assume this AI system would not be used for?
MEASURE	Applies quantitative and qualitative tools to assess risk across the lifecycle	Are we measuring drift, or just measuring at launch?
MANAGE	Prioritizes, resources, and actions the response — then feeds lessons back to GOVERN	Does anything we learn in production change the policy?

Most organizations can point to artifacts for GOVERN. Far fewer can show a MAP document for a specific deployed AI system. Almost none have MEASURE instrumented as an ongoing signal rather than a one-time test.

The gap pattern that actually predicts failure

Here’s the part the generic AI RMF explainer post skips: which combination of strong/weak functions you have tells you why your program is weak, not just that it’s weak.

What we see in the field	What’s really going on	Where to focus first
GOVERN complete, MAP/MEASURE weak	Policy was written, never operationalized against a real system	Run a system-level risk assessment (MAP) on your highest-exposure AI use case — not a hypothetical one
MAP done, MEASURE absent	Risk was identified in a workshop, never instrumented	Define metrics for each identified risk and put monitoring behind them
MEASURE present, no MANAGE action	You’re collecting data nobody owns	Assign a risk owner and a review date to every metric that’s tracked
Strong technical controls, weak societal-risk view	Engineering-led program with no outside perspective	Bring legal, ethics, or affected-user perspective into MAP 3 and MEASURE 2
No lifecycle coverage	Only deployment gets attention	Extend coverage back to design/development and forward to decommission

If you recognize your organization in the first row — GOVERN strong, everything else thin — that’s not a failed program. That’s a program that stopped at the easiest 20%.

Financial services is the hard mode of AI RMF, not the easy mode

Every AI RMF post talks about bias in hiring algorithms. Financial services has that problem and three others stacked on top of it:

Credit decision fairness — disparate impact analysis isn’t optional; it’s tested against the EEOC’s four-fifths rule, and adverse action notices have to be explainable to a person, not just accurate to a model.
Explainability under legal obligation — ECOA and CFPB guidance mean MEASURE 2 (“system evaluated for trustworthiness”) isn’t a nice-to-have property, it’s the difference between a defensible decision and a discrimination claim.
Fraud model drift — a fraud-detection model that was 94% accurate at launch and hasn’t been re-measured since is a MEASURE 3 gap with a very expensive failure mode.

For a platform handling M&A due diligence or financial data rooms, the stakes compound further: the AI risk profile has to sit on top of an existing confidentiality and access-control posture, not replace it.

Building the profile: current state vs. target state

The mechanism that actually closes gaps is simpler than the framework makes it look:

Scope — pick the AI systems in scope. Not “all AI, eventually.” One system, real and deployed.
Rate current state — for each of the 19 categories: Not Started (0) → Partial (1) → Implemented (2) → Optimized (3).
Set target state — driven by regulatory exposure and risk tolerance, not aspiration.
Gap = Target minus Current. Anywhere that’s positive is where the roadmap lives.
Weight by risk, not by ease. The gap that’s easiest to close isn’t necessarily the one that matters.

Most organizations we assess land at Implementation Tier 1 or 2 — ad hoc or risk-informed. Tier 3 (Repeatable) is the realistic target for a regulated environment. Tier 4 (Adaptive) is for organizations where AI is the product, not a feature.

Why AI RMF pairs with ISO 42001 instead of competing with it

AI RMF is voluntary; it doesn’t get you a certificate. ISO/IEC 42001 does. The two aren’t rival frameworks — AI RMF is the risk methodology; ISO 42001 is the management system that makes it auditable.

Concretely: GOVERN 1 (policies in place) maps to ISO 42001 Clause 5 and Annex A.2. MEASURE 3 (ongoing monitoring) maps to Clause 9.1. If you’re already running an ISMS under ISO 27001, this isn’t a parallel program — it’s an extension with about 70% conceptual overlap and a genuinely new 30% around bias, explainability, and AI-specific incident response.

That’s the sequence that actually gets audited in production: AI RMF gives you the risk logic; ISO 42001 gives you the certifiable structure to prove you’re running it.

The one-sentence version

If your AI governance program can describe its policy but can’t name the owner, the metric, and the last review date for a single deployed AI system — you don’t have a gap in one function. You have a program that only did the part that doesn’t get tested.

Building or auditing an AI risk management program against NIST AI RMF, ISO 42001, or the EU AI Act? That’s the work — happy to talk through where your program actually stands.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

DISC InfoSec blog

Tags: AI RMF, NIST AI RMF

Jun 29 2026

ISO/IEC 27001:2022 — The Compliance Bedrock Every Serious InfoSec Program Is Built On

Category: CISO,Information Security,ISO 27k,vCISO — disc7 @ 8:53 am

ISO/IEC 27001:2022 — The Compliance Bedrock Every Serious InfoSec Program Is Built On

By Disc | Principal Consultant, DISC InfoSec

There’s a question I get from almost every B2B SaaS and financial services client at some point:

“Which compliance framework should we start with?”

My answer is almost always the same: ISO/IEC 27001.

Not because it’s the flashiest. Not because a regulator is threatening a fine. But because it is the only framework that forces you to build a real information security management system — one your entire compliance stack can grow on top of.

Here’s why.

What ISO 27001 Actually Is (And Isn’t)

ISO/IEC 27001:2022 is the international standard for Information Security Management Systems (ISMS). It’s published by the International Organization for Standardization and the International Electrotechnical Commission, and it applies to any organization, any size, any sector.

What it is not is a checklist. It is a management system standard — meaning it requires your organization to define its context, assess risk, implement controls, measure performance, and continuously improve. That PDCA (Plan-Do-Check-Act) discipline is exactly what makes it so durable and so transferable.

The 2022 version restructured the Annex A control library from 114 controls across 14 domains down to 93 controls across 4 themes — Organizational, People, Physical, and Technological — and added 11 new controls for cloud security, threat intelligence, data masking, secure coding, and more. Every organization with a 2013 certification was required to transition by October 2025.

If you’re still operating on a 2013-era ISMS, you’re already out of conformance.

The Mandatory Clause Framework: Where the Real Value Lives

ISO 27001’s Clauses 4 through 10 apply to every organization without exception. This is where the management system lives — not in the Annex A controls, but in the operational discipline the clauses require:

Clause 4 — Know your context. Who are your stakeholders? What are their expectations? What’s in scope?
Clause 5 — Leadership owns security. A signed policy isn’t a checkbox. It’s a commitment from the top.
Clause 6 — Plan your risk treatment. A formal risk register, a risk treatment plan, and a Statement of Applicability (SoA) are mandatory outputs.
Clause 7 — Support structures. Competence records, awareness training, documented procedures.
Clause 8 — Operate your controls. Evidence that risk treatment is actually executing, not just documented.
Clause 9 — Measure and audit. KPIs, internal audits, management review — the cadence that prevents ISMS drift.
Clause 10 — Improve. Nonconformities get documented. Corrective actions get tracked. The system learns.

This is not bureaucracy for its own sake. This is the operational skeleton that every mature compliance program eventually needs to build — ISO 27001 just requires you to build it on day one.

Why ISO 27001 Is the Foundation Other Frameworks Stand On

Here’s the practitioner reality: most compliance frameworks are control libraries with a certification stamp. ISO 27001 is different — it’s a management system that happens to include a control library.

That distinction matters enormously when you’re trying to layer frameworks.

SOC 2

The AICPA’s Trust Services Criteria map heavily to ISO 27001 Annex A. If you have implemented access control (A.5.15–5.18), incident response (A.5.24–5.28), supplier security (A.5.19–5.22), and availability controls (A.5.29–5.30), you have already addressed the majority of CC6, CC7, A1, and C1 criteria. ISO 27001 gives SOC 2 auditors a documented ISMS they can rely on — which typically compresses audit timelines and reduces evidence burden.

ISO 42001 (AI Management Systems)

ISO/IEC 42001:2023 — the AI governance standard — was explicitly designed to be compatible with ISO 27001. The two standards share the same Annex SL high-level structure, meaning risk assessment methodology, documentation requirements, internal audit cadence, and management review processes are directly reusable. Organizations that have ISO 27001 in place have an immediate head start on 42001 implementation. For AI-powered SaaS companies facing EU AI Act pressure, this integration is not optional — it’s strategic.

EU AI Act

The EU AI Act’s requirements for high-risk AI systems — risk management systems, data governance, technical documentation, human oversight, robustness — all assume a baseline of information security hygiene. ISO 27001 provides that baseline, particularly through its new 2022 controls: A.8.9 (configuration management), A.8.28 (secure coding), A.5.23 (cloud services security), and A.8.12 (data leakage prevention). Regulators and notified bodies will look for this foundation.

NIST CSF 2.0

The NIST Cybersecurity Framework’s six functions — Govern, Identify, Protect, Detect, Respond, Recover — map cleanly to ISO 27001. The Govern function aligns to Clauses 4, 5, and 6. Protect maps to Annex A’s organizational and technological controls. Detect and Respond align to incident management controls A.5.24–5.28. If you’re pursuing FedRAMP or CMMC, your ISO 27001 ISMS is the documentation backbone the NIST SP 800-53 assessor will want to see.

GDPR and Privacy Regulations

ISO 27001 doesn’t cover privacy by itself — that’s ISO 27701 territory. But the ISMS structure, supplier security controls (A.5.19–5.22), and information classification controls (A.5.12–5.13) provide the security safeguards that GDPR Article 32 requires. A GDPR compliance program built on an ISO 27001 ISMS is structurally sounder than one built from scratch.

The Business Case: Why Enterprises and Governments Demand It

ISO 27001 certification signals something that no internal policy document can: an independent third party has verified your security management system meets a globally recognized standard.

For vendor selection in enterprise and financial services, that matters. For cross-border contracts in the EU, UK, APAC, and Middle East, it’s often a baseline requirement. For regulated industries — healthcare, fintech, government supply chains — it can be the difference between getting on the shortlist or getting cut from procurement.

This is why I tell clients: ISO 27001 is not just a compliance achievement. It’s a revenue enabler.

What “Foundation” Actually Means in Practice

When I use the word foundation, I mean something specific: the mandatory documentation that ISO 27001 requires you to produce becomes the evidentiary infrastructure for every other program you layer on top.

Your ISO 27001 ISMS produces:

A scoped asset inventory (feeds SOC 2, FedRAMP, CMMC)
A formal risk register (feeds ISO 42001, NIST AI RMF, EU AI Act)
A Statement of Applicability (feeds gap analysis for any other framework)
An internal audit programme (feeds SOC 2 Type 2, FedRAMP ConMon)
A supplier security process (feeds GDPR Article 28, SOC 2 CC9)
Management review minutes (feeds governance evidence for any board-level framework)

You build it once. Every other framework benefits.

The Practitioner’s Bottom Line

We’ve implemented ISO 27001 for organizations ranging from boutique SaaS companies to financial services platforms handling sensitive deal data. The pattern is consistent: the organizations that invest in a real ISMS — not a documentation exercise, but an operational management system — spend dramatically less time and money on every subsequent compliance program.

ISO/IEC 27001:2022 is not the finish line. It’s the starting block.

If your organization is serious about security — not just compliant on paper, but operationally disciplined — this is where you begin.

DISC InfoSec specializes in ISO 27001 and ISO 42001 implementation, vCISO and vCAIO services, and AI governance for B2B SaaS and financial services organizations. We are a PECB Authorized Training Partner and have led ISO 42001 Stage 2 certification engagements for production AI systems.

Ready to build a compliance program that actually holds up? Let’s talk. info@deurainfosec.com

→ https://www.deurainfosec.com/iso-27001-consulting/

#ISO27001 #InformationSecurity #ISMS #Compliance #CyberSecurity #GRC #AIGovernance #ISO42001 #vCISO #DISCINFOSEC

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

DISC InfoSec blog

Tags: isms, iso 27001, security program

Jun 26 2026

One Audit – Four Standards – Zero Duplication

Category: GDPR,Information Security,ISO 27k,ISO 42001,NIST CSF — disc7 @ 11:16 am

One Audit. Four Standards. Zero Duplication.

How to Build a Master Questionnaire as Your Single Source of Truth for ISO 27001, ISO 42001, NIST 800-53, and GDPR

I want to tell you about a problem that is quietly draining compliance teams at SaaS companies right now — and a structural fix that changed how we think about audits entirely.

Here is the situation most security and compliance leaders find themselves in. You hold ISO 27001 certification. Your enterprise customers require NIST 800-53 Rev 5 verification. GDPR applies because you handle European personal data. And now, with AI baked into your product, ISO 42001 is on the table too. Four frameworks. Four sets of controls. Four different auditors asking different versions of the same fundamental questions.

The instinctive response is to build four compliance programs — one for each standard. Four spreadsheets, four evidence libraries, four cycles of internal prep, four rounds of answering the same question about your access control policy worded slightly differently each time.

We did this at client. It was expensive, repetitive, and structurally fragile. Every time a policy changed, we had to update it in four places. Evidence collected for one audit sat invisible to the others. The left hand genuinely did not know what the right hand was doing.

Then we asked a different question: What if there was only one audit?

The Insight That Changes Everything

Across ISO 27001:2022, ISO 42001:2023, NIST SP 800-53 Rev 5, and GDPR, the vast majority of what auditors actually want to know falls into the same 18 operational domains: governance, risk management, access control, data protection, cryptography, incident response, business continuity, supplier management, secure development, and so on.

The standards differ in language, structure, and emphasis. But the underlying security and privacy reality they are probing — your policies, your controls, your evidence — is the same reality. An ISO 27001 auditor asking about your access control policy (A.5.15) and a NIST assessor asking about AC-1 are fundamentally asking the same organization the same question. Your Access Control Policy v1.3 answers both of them.

This is the foundation of the Master Questionnaire approach: write the question once, map the answer to every standard it satisfies simultaneously.

Why Most Multi-Standard Programs Fail Structurally

Before describing what to build, it is worth being precise about why the typical approach breaks down. The problem is not effort or intention — compliance teams work hard. The problem is architecture.

Most organizations build what I call parallel catalogs: one spreadsheet or GRC module per standard, each with its own question set, its own evidence columns, its own status tracking. When the ISO 27001 auditor asks about incident response and the GDPR auditor asks about breach notification, they get two separate answers pointing to the same IR Procedure — but there is no structural connection between them. If you update the procedure, you have to remember to update both rows in both sheets. You usually do not. Inconsistencies accumulate. Auditors notice.

The second failure is ID scheme collision. This sounds technical but it matters enormously in practice. If your internal questionnaire uses “IR-01” for your Incident Response domain questions and NIST SP 800-53 uses “IR-1” for the same family, you end up with ID conflicts that make cross-referencing impossible. You cannot write a formula or filter that reliably maps one to the other. We ran into exactly this problem in our own workbook, discovering 173 NIST Moderate baseline controls that existed only in a standalone NIST catalog with no connection whatsoever to the master question set.

The third failure is scope mismatch. NIST SP 800-53 Rev 5 Moderate baseline has approximately 235 distinct controls across 20 families when enhancements are included. ISO 27001:2022 has 93 Annex A controls. ISO 42001:2023 has 38 AI-specific controls. GDPR has 99 Articles. Organizations routinely under-scope their questionnaires, sampling 26 or 30 NIST controls and calling it “covered.” A real Moderate baseline assessment covers every control — AC-1 through SR-12, including every enhancement number that the baseline requires.

The Architecture of a Single Source of Truth

Here is how to build it correctly.

Start with 18 operational domains, not four standards.

The domains should reflect how your organization actually operates: Governance & Policies, Scope & Context, Risk Management, Access Control & Identity, Data Protection & Privacy, Cryptography & Key Management, Network & Infrastructure Security, Secure Development, Incident Response, Business Continuity, Supplier & Third-Party Management, Physical & Environmental Security, Human Resources Security, Audit Logging & Monitoring, Configuration & Change Management, AI Governance, Compliance & Internal Audit, and Cross-Border Data Transfers.

Every question you write lives in one of these domains. The domain structure is standard-agnostic — it reflects your operational reality, not any single framework’s chapter structure.

Write questions that satisfy multiple standards simultaneously.

Take access control as an example. Rather than writing four separate questions — one citing ISO 27001 A.5.16, one citing NIST AC-2, one citing GDPR Art. 32, one citing ISO 42001 A.6.2.2 — you write one question: “Describe the complete joiner-mover-leaver process. How are accounts created, modified, and deactivated? What is the maximum time to deprovision a terminated user?”

This single question satisfies ISO 27001:2022 A.5.16 and A.5.18, NIST SP 800-53 Rev 5 AC-2, AC-2(1), AC-2(3), and AC-2(5), and GDPR Art. 32. One answer. Four standards. That is not a shortcut — that is what a mature account management process actually looks like when described completely.

Use a collision-free ID scheme from the start.

This is a technical detail that pays significant dividends. Cross-standard questions should use domain-based prefixes that do not clash with any standard’s own naming: G- for Governance, A- for Access Control, INC- for Incident Response (not IR-, which collides with the NIST IR family), BCP- for Business Continuity, CFG- for Configuration Management (not CM-, which collides with NIST CM), CRY- for Cryptography, and so on.

NIST-specific questions — those covering Moderate baseline controls not addressed by any cross-standard question — should use a clearly distinct scheme: NIST-{family}-{sequence}, for example NIST-AC-07 for AC-7, NIST-PE-04 for PE-13. This makes the source of every question unambiguous and allows you to filter programmatically by standard without collision.

The Master tab is the only place answers live.

Every auditor view — ISO 27001 tab, ISO 42001 tab, NIST tab, GDPR tab — is a filtered subset of the Master, not an independent document. When the answer to a question changes, you update it once in the Master. The filter propagates to all auditor views automatically. If you find yourself maintaining two versions of an answer, your architecture has a flaw.

Add a Question Source column.

This single column distinguishes between cross-standard questions (one question, many standards) and NIST-specific questions (one control, one question). It tells any auditor looking at the sheet exactly what they are looking at and why the question exists. It also tells your team where to invest effort — cross-standard questions with a “★ Shared” marker satisfy three or more frameworks simultaneously and should be answered first.

What the Numbers Look Like in Practice

When we implemented this at client, the numbers clarified the approach nicely.

We ended up with 213 total questions in the Master: 104 cross-standard questions covering all 18 operational domains, and 109 NIST-specific questions covering NIST Moderate baseline controls that needed dedicated coverage. The NIST auditor view contains 212 questions — covering 235 distinct NIST controls — all filtered directly from the Master. The ISO 27001 view contains 209 questions. The GDPR view contains 206. The ISO 42001 view contains 138, reflecting that ISO 42001’s scope is intentionally narrower.

Of the 213 total questions, 56 are marked as shared controls — meaning a single answer to that question satisfies three or more standards simultaneously. These 56 questions are the highest-leverage evidence collection effort in your entire audit programme. Answer them well and you have satisfied the core control requirements of all four frameworks for the most critical domains: risk management, access control, encryption, incident response, supplier management, data protection, logging, and business continuity.

Before this restructure, we had a v3 workbook with 104 questions in the Master and 187 in a standalone NIST tab with zero structural connection between them. The root cause was that the NIST tab had been built as a separate catalog with NIST family-based IDs that clashed with our domain IDs, making cross-referencing impossible. This is a common mistake and worth naming explicitly: a NIST tab that cannot be proven to be a filtered view of the Master is not a single source of truth — it is a second source of truth, which is the same as no single source of truth at all.

The Columns That Make It Work

A Master Questionnaire has a specific anatomy. Every row needs:

Q-ID — unique, collision-free identifier following your scheme.

Domain — the operational domain, not the standard’s chapter.

Audit Question — written to satisfy all applicable standards simultaneously, framed around your actual controls and evidence.

Audit Type — Document Review, Technical Review, Interview, Sample, or combinations. This tells both your team and the auditor what kind of evidence the question expects.

ISO 27001:2022 reference — official Annex A control IDs (A.5.1 through A.8.34) and Clause references (Cl.4 through Cl.10). Not approximated — exact.

ISO 42001:2023 reference — official Annex A control IDs (A.2.2 through A.10.4) and Clause references. ISO 42001 Annex A objectives (A.x.1 entries) are not controls — the controls begin at A.x.2. This distinction matters when an ISO 42001 auditor checks your SoA.

NIST SP 800-53 Rev 5 reference — official control IDs with enhancement numbers. AC-2(1) is a different control from AC-2. A Moderate baseline assessment distinguishes between them. If your questionnaire collapses AC-2 and all its enhancements into a single cell without specifying which enhancements apply, your NIST assessor will push back.

GDPR reference — specific Article numbers at sub-article precision. Art. 5(1)(c) is different from Art. 5(1)(e). Art. 28(3) specifies the mandatory clauses in a DPA. Approximated references like “Art. 32 generally” are insufficient for a DPO-level review.

Answer column — blank, awaiting your response. This is the most important column in the workbook. It is where your security reality meets the standards’ requirements.

Status — a dropdown: Implemented, Partial, Not Implemented, N/A, Not Tested. The Partial status is particularly important — it tells auditors and management exactly where gaps exist without overstating or understating compliance.

Evidence / Document Reference — the policy name, version, section, screenshot, log excerpt, or configuration that proves the answer. This column is pre-filled with hints when you build the questionnaire (e.g., “Access Control Policy v1.3; 90-day review evidence; LastPass configuration”) and updated with actual references during audit preparation.

Question Owner — the individual responsible for providing the answer and evidence. Compliance does not happen in a CISO’s office alone. Owners span IT, HR, Legal, DevOps, the AI Officer, and the DPO.

Auditor Notes — reserved for the auditor. Your team does not pre-fill this column. It is the auditor’s workspace during the actual audit session.

Shared Control flag — a star marker for questions satisfying three or more standards. Your audit preparation team should complete all starred questions first. They represent the core of your compliance posture across every framework.

The Audit Session Experience

Here is what this looks like in practice when you sit down with an auditor.

Your ISO 27001 auditor receives the ISO 27001 filtered view tab. They see 209 questions, each with official Annex A or Clause references, your pre-populated answer, a status, and an evidence reference. They work through the Auditor Notes column adding their observations. They do not need to navigate the NIST questions or the AI governance section unless a control overlaps.

Your NIST assessor receives the NIST view tab: 212 questions covering 235 controls across all 20 families from AC through SR. Both cross-standard questions (where your Access Control Policy satisfies AC-1, AC-2, AC-3 simultaneously) and NIST-specific questions (AC-7 lockout thresholds, AC-11 device lock, SC-15 collaborative device controls) are visible, with the Question Source column clearly labeling each type.

Your DPO or privacy auditor receives the GDPR view: 206 questions covering Articles 5 through 83, with cross-references to the ISO 27001 and ISO 42001 controls that satisfy the same requirement. The RoPA question, the DPIA question, the data subject rights process question, the breach notification procedure — all answered once in the Master, surfaced here for the privacy auditor’s review.

What none of these auditors receive is a contradictory answer. Because there is only one answer. There is only one Master.

The AI Governance Layer

ISO 42001:2023 deserves specific attention because it is the newest of the four standards and the one most organizations are building from scratch rather than extending from existing programs.

The standard requires several things that have no direct analog in ISO 27001 or NIST. AI System Impact Assessments (AISIAs) are mandatory for every AI system in scope — a structured analysis of potential impacts on individuals, groups, and society, resulting in a Low, Medium, or High impact classification. This feeds directly into how much human oversight, transparency, and testing is required for each system. Your AI governance questions need to cover this lifecycle: system registration, AISIA, responsible design principles (A.6.1.3), verification and validation testing (A.6.2.4), controlled deployment (A.6.2.5), monitoring (A.8.5), and AI-specific incident management (A.8.4).

The AI data governance controls — A.7.2 through A.7.6 covering data quality, provenance, and preparation — have meaningful overlap with GDPR’s data minimisation (Art. 5(1)(c)), purpose limitation (Art. 5(1)(b)), and privacy by design (Art. 25) requirements. A single well-written question about AI data governance can cover all of these simultaneously, but only if you know both standards well enough to write it that way.

The EU AI Act adds a classification layer that sits above ISO 42001 rather than within it: your AI systems need to be assessed against the Act’s risk tiers (prohibited, high-risk Annex III, limited risk, minimal risk) with resulting compliance obligations. This is an AIX-domain question in the Master with no NIST equivalent — which is fine, because not every question needs to satisfy all four standards. The single source of truth principle does not mean every question covers every standard; it means every answer lives in one place.

Five Principles to Build By

If I were starting this process from scratch at a new organization, I would anchor on five principles from day one.

Official control IDs only. Approximated references create ambiguity that auditors exploit. If your ISO 27001 reference says “A.5 generally” instead of “A.5.15; A.5.16; A.5.18,” a thorough auditor will ask which specific controls you are claiming coverage for and you will have to reconstruct the mapping under pressure. Use the exact IDs from the published standards. ISO 27001:2022 Annex A runs from A.5.1 to A.8.34. NIST 800-53 Rev 5 AC-2(1) is a separate control from AC-2. These distinctions are in the standards for a reason.

Full coverage, not sampling. A Moderate NIST baseline assessment covers approximately 235 controls. An ISO 27001 audit covers all 93 Annex A controls. Sampling — picking representative controls from each family — may satisfy a checkbox exercise but it will not satisfy a thorough assessor and it will not actually tell you where your gaps are. The discipline of building complete coverage is also the discipline of discovering what you do not have implemented yet.

One answer, not four. If you catch yourself writing the same answer in two different tabs, your architecture is broken. Fix the architecture, not the duplicate. The structural constraint — all auditor views are filtered subsets of the Master — should make duplication physically impossible.

Gaps are information, not failure. The Partial and Not Implemented status options are not admissions of guilt — they are the output of an honest audit programme. A questionnaire where everything is marked Implemented before an auditor has looked at it is not a compliance programme; it is a liability. Real compliance posture requires knowing where you stand, including the uncomfortable parts.

The questionnaire is a living document, not a pre-audit scramble. The most valuable thing a Master Questionnaire does is shift compliance from a periodic event to a continuous state. When your IR procedure changes, you update the INC-01 answer. When you onboard a new AI service provider, you update the AIX-09 answer and the SUP-03 answer. The questionnaire should be reviewed quarterly, updated continuously, and owned by named individuals — not assembled in the three weeks before an auditor arrives.

A Note on AI-Assisted Compliance

One of the most significant changes in compliance practice over the last two years is the ability to use AI tools to populate questionnaire answers from an organization’s existing knowledge base — policies, procedures, security documentation, vendor assessments, architecture documents.

This does not replace human judgment. The Answer column in a Master Questionnaire still requires a human to verify accuracy, attach actual evidence references, and set a status they are willing to defend in an audit. But it dramatically compresses the time between “questionnaire template built” and “questionnaire ready for auditor review.”

At ShareVault, where our knowledge base includes our Security Policy, Access Control Policy, AI Management Policy, Incident Response Procedure, Risk Assessment Procedure, Privacy Policy, and Security & Availability documentation, an AI tool can populate an initial draft of most answers from these sources and flag which questions have insufficient documentation to answer — which is itself valuable information.

The key discipline is the same as for all AI-assisted work: the human remains accountable for the output. The AI drafts; the owner reviews, corrects, and signs off. The auditor evaluates the answer, not the method used to produce it.

Where to Start

If you are managing compliance across multiple standards and you recognize the structural problems described here, the path forward is straightforward even if the work is substantial.

Start with a gap analysis of what you currently have. Count your actual questions per standard. Map each one to the official control ID it is claiming to satisfy. Find the NIST families you have not covered at all (typically MA, MP, PE, PL, and SR are the most common gaps). Identify whether your auditor view tabs are provably filtered subsets of a master, or independent catalogs that happen to cover some of the same ground.

Then rebuild the Master with the architecture described above. It takes time to write 213 questions with precise official references. But you write them once. After that, every audit, every evidence collection cycle, and every questionnaire from a customer or prospect draws from the same source.

That is the value of a single source of truth. Not that compliance becomes easy — but that every effort you invest in it compounds instead of fragmenting.

The client team holds ISO 27001:2022 certification (SHA-27K-PRI) and ISO 42001:2023 certification (SHA-AIMS-20260129), maintains NIST SP 800-53 Rev 5 Moderate baseline verification, and operates under GDPR as both a data controller and processor for European customers. The Master Audit Questionnaire described in this article was built through iterative refinement of our own internal compliance programme.

#InformationSecurity #Compliance #ISO27001 #ISO42001 #NIST #GDPR #AuditPreparation #AIGovernance #DataProtection #CyberSecurity #GRC #CISO #DPO #SaaS #RiskManagement

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Continue reading “One Audit – Four Standards – Zero Duplication”

Tags: gdpr, iso 27001, ISO 42001, NIST 800-53, One Audit

eu-ai-act-classifier Download

Jun 23 2026

Most companies deploying AI in the EU still don’t know what tier they’re in

Category: AI,AI Risk,Information Security — disc7 @ 11:12 am

Most companies deploying AI in the EU still don’t know what tier they’re in

Most companies deploying AI in the EU still don’t know what tier they’re in.

That’s not an opinion. It’s what I see in every engagement.

The EU AI Act (Reg. 2024/1689) has been in force since August 2024. Prohibited practices have been enforceable since February 2025. GPAI obligations kicked in August 2025. And yet I regularly speak to legal, compliance, and technology teams who cannot answer the most basic question:

Is our AI system prohibited, high-risk, limited risk, or minimal risk?

The confusion is understandable. The regulation is 458 pages. The AI Omnibus (May 2026) extended several deadlines but added a 9th prohibited practice category. The Annex III high-risk use case areas are dense and context-dependent. Article 6 classification logic has two paths, each with its own exceptions.

Most organizations are either over-panicking (“everything we do is high-risk”) or under-preparing (“we have until 2027, it’s fine”). Both postures are wrong, and both are expensive.

So I built a free tool.

The EU AI Act Risk Classifier is a standalone, open HTML tool that runs a full classification assessment against your AI system in under 60 seconds.

Describe your system in plain language. Select your role — provider, deployer, importer, distributor. Hit classify.

The tool runs an 8-step analysis covering:

→ Prohibited practices screen — all 9 Art. 5 categories, including the AI Omnibus addition effective December 2026

→ Risk tier determination — Art. 6 Path A (Annex I product safety components) and Path B (Annex III use cases), with specific area citations when high-risk applies

→ Key obligations — prioritised by Article number and your specific role

→ Compliance deadline — the correct date for your tier, accounting for the AI Omnibus extensions (Annex III standalone systems: 2 December 2027; Annex I embedded products: 2 August 2028)

It’s not a substitute for legal counsel. It’s a starting point that gives you and your counsel something concrete to work from — a defensible first-pass classification with Article citations, not a vendor’s vague risk score.

Who this is for

If you are a provider placing an AI system on the EU market — you need to know your tier before you start building your Art. 9 risk management system or Art. 17 quality management system. Classification is the prerequisite for everything else.

If you are a deployer — an enterprise, financial institution, or SaaS company using AI under your own authority — your Art. 26 obligations depend entirely on whether the system your vendor sold you is high-risk. Most vendors won’t tell you clearly. This tool helps you verify.

If you are a GRC, legal, or compliance professional advising clients on EU AI Act readiness — this is a structured intake tool. Run it before the first scoping call. Walk in with a provisional classification, not a blank page.

The deadline reality check

The AI Omnibus gave many organizations a false sense of relief. Yes, the high-risk Annex III deadline moved to December 2027. But:

Prohibited practices (Art. 5) have been enforceable since February 2025. The 9th prohibition on non-consensual synthetic intimate imagery applies from December 2026.
GPAI model obligations (Arts. 53–55) have applied since August 2025. If you are building on a foundation model, you have deployer obligations now.
Art. 50 transparency obligations for chatbots and synthetic media apply from August 2026.

The extension bought time for high-risk conformity assessment. It did not buy time for everything else.

Get the tool

The classifier is a free, self-hostable HTML file. No login. No data collection. Your API key is used in-memory only — never stored, never logged.

Drop it in your browser. Classify your system. Then call us.

→ Download the EU AI Act Risk Classifier

If the classification comes back high-risk and you need help navigating Arts. 9–17, a gap assessment, or an ISO 42001 implementation to underpin your AIMS — that’s exactly what DISC InfoSec does.

Disc Deura is Principal Consultant at DISC InfoSec (Deura Information Security Consulting LLC). CISSP · CISM · ISO 27001 Lead Implementer · ISO 42001 Lead Implementer · PECB Authorized Training Partner. Two decades across KPMG, IBM, and Intel/McAfee FoundStone. EU AI Act and ISO 42001 pioneer-practitioner.

#EUAIAct #AIGovernance #ISO42001 #AICompliance #GRC #CISO #ArtificialIntelligence #Compliance #DataPrivacy #RegulatoryCompliance

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Schedule a consultation or drop a note below: info@deurainfosec.com

Tags: EU AI Act, EU AI Act classifier

Jun 22 2026

You Can’t Certify What You Haven’t Mapped: The Case for an ISO 27001 Gap Assessment

Category: Information Security,ISO 27k — disc7 @ 1:02 pm

You Can’t Certify What You Haven’t Mapped: The Case for an ISO 27001 Gap Assessment

Every ISO 27001 certification journey starts the same way — with a question that sounds simple and isn’t: Where are we right now?

That question is the gap assessment. And whether you’re a 20-person SaaS company trying to win enterprise deals or a mid-market firm responding to customer security questionnaires, the gap assessment is the most valuable thing you’ll do before you spend a dollar on tooling, a minute in a consultant’s workshop, or a day preparing for a Stage 1 audit.

Here’s what it is, why it matters, and how a structured approach turns a wall of compliance requirements into an honest six-month roadmap.

What Is an ISO 27001 Gap Assessment?

An ISO 27001 gap assessment is a structured comparison of your current state against the requirements of ISO/IEC 27001:2022 — across two dimensions:

Mandatory clauses (4–10): These are non-negotiable structural requirements. They cover how your organization defines its context (Clause 4), leadership commitment (Clause 5), risk management (Clause 6), operational controls (Clause 8), performance measurement (Clause 9), and continual improvement (Clause 10). Every single one must be addressed. You cannot exclude them.

Annex A controls (A.5–A.8): These are 93 controls across four domains — Organizational, People, Physical, and Technological. Unlike the mandatory clauses, you can exclude Annex A controls from your scope — but every exclusion must be formally justified in your Statement of Applicability (SoA). “We forgot about that one” is not a justification.

The gap assessment looks at each requirement, asks whether evidence currently exists to satisfy it, notes what’s missing, and assigns a severity to the gap. The output isn’t a score. It’s a prioritized remediation list and a realistic timeline.

Why Bother? The Business Case Is Concrete

Organizations skip the gap assessment for the same reason they skip the architect before construction: it feels like overhead when you just want to get moving. That reasoning fails at the first audit.

Here’s what the gap assessment actually buys you:

It stops you from building in the wrong order. ISO 27001 has hard dependencies. You cannot run a compliant risk assessment before you’ve documented your methodology (Clause 6.1.1). You cannot write a valid Statement of Applicability before you’ve completed the risk treatment plan (Clause 6.1.3). You cannot close the loop on continual improvement without internal audit findings feeding into it (Clause 10). Organizations that skip the gap assessment routinely discover at Stage 1 that they’ve built Phase 3 before completing Phase 1. That’s expensive rework.

It surfaces the controls that actually take time. Ask any ISO 27001 implementer what delayed their certification, and you’ll hear the same two answers: the asset register and the risk assessment. Both are downstream dependencies for everything else. The asset register isn’t glamorous, but without it, your risk assessment is a fiction and your SoA is guesswork. The gap assessment forces you to confront this at the beginning, not six weeks before Stage 2.

It gives leadership an honest brief. The gap assessment is the most credible document you can put in front of your CISO, CTO, or board when asking for budget. It’s not a vendor deck. It’s a bill of materials: here’s what we have, here’s what we need, here’s how long it realistically takes. Management commitment isn’t something you get once and bank — it needs to be sustained through a multi-month implementation. The gap assessment keeps everyone calibrated.

It protects your audit investment. ISO 27001 certification costs real money — certification body fees, consultant time, internal hours. A gap assessment is insurance on that investment. Organizations that go into Stage 1 with an honest gap analysis spend their audit time demonstrating maturity. Organizations that don’t spend it discovering they’re missing a signed Information Security Policy or a single completed management review.

The Implementation Roadmap: Six Months from Scratch

Based on the structure of a rigorous gap assessment across all 93 Annex A controls and the 25 mandatory clause requirements, here’s what a realistic implementation looks like.

Phase 1 — Foundation (Weeks 1–6)

Do these first or nothing else works.

This phase is about structural prerequisites. Without them, you cannot run a compliant risk assessment, write a defensible SoA, or pass Stage 1.

The critical outputs here are: a signed ISMS scope document (no scope, no certification), a context and stakeholder analysis that drives policy and control selection downstream, documented management commitment with budget and RACI, a signed Information Security Policy, a completed asset register, and a defined risk assessment methodology — documented before you run the assessment.

The asset register deserves a dedicated call-out. It is the foundation for nearly every Annex A control that follows. Organizations chronically underestimate how long it takes to build an accurate, comprehensive register covering data assets, software, hardware, and cloud services. Start here, not when you feel ready.

Phase 2 — Core Controls (Weeks 7–14)

Treat risks and build the control baseline.

With the foundation in place, Phase 2 is where you run the formal risk assessment, complete the risk treatment plan, and produce the Statement of Applicability — the single most scrutinized document at any ISO 27001 audit. Every one of the 93 Annex A controls must appear in the SoA with a decision: implement, accept risk, or exclude with justification.

The technical controls that come online in this phase include IAM with MFA (auditors have moved well past treating MFA as optional), privileged access management, endpoint and malware protection, patch management with defined severity SLAs, and log aggregation. Alongside the technical stack, the core policy suite gets written and communicated: Acceptable Use Policy, Access Control Policy, Incident Response Plan, Cryptography Policy, and Remote Working Policy.

Security awareness training also launches in Phase 2. Auditors don’t just check completion records — they informally quiz staff. If your employees can’t articulate how to report a security incident, your training program didn’t land.

Phase 3 — Operational Readiness (Weeks 15–20)

Prove the ISMS is running, not just documented.

This is where the gap between policy and practice gets closed. The most common Stage 2 finding isn’t missing documentation — it’s documentation that describes controls nobody is actually operating.

Phase 3 focus areas: supplier security (every material vendor needs an assessment; auditors review actual contract language for IS clauses), a tested incident response plan (a tabletop exercise is the minimum; untested plans don’t satisfy auditors), a documented and tested backup restoration process (backups alone don’t count), a running vulnerability scanning cadence with critical CVEs remediated, configuration baselines against a recognized standard like CIS Benchmarks, and the beginning of IS objective measurement so you have data to present at management review.

Phase 4 — Audit Readiness (Weeks 21–26)

Close the loop before Stage 1.

The final phase is about demonstrating a functioning ISMS, not a perfect one. Auditors are looking for a system that works — that captures findings, generates corrective actions, and learns from them. Zero nonconformities is not the goal. A functioning corrective action process is.

Phase 4 deliverables: a completed internal audit covering all clauses with findings logged (at least one full cycle must be complete before Stage 2), signed management review minutes covering all required inputs, open corrective actions with root cause analysis in progress, and a Stage 1 readiness check against the mandatory documentation list.

The Hard Reality of Timeline Compression

Six months is achievable for a focused organization starting from scratch. It is not guaranteed, and the most common reason programs stall is Phases 1 and 2 taking twice as long as planned.

The two failure modes I see consistently:

Asset register underestimation. Organizations discover mid-Phase 2 that their asset inventory is incomplete, which invalidates the risk assessment they’ve already invested in. Scope the asset register effort honestly at the outset.

Risk assessment scope creep. Without a documented methodology agreed to in Phase 1, the risk assessment becomes a moving target. Define your methodology — asset-based, scenario-based, or hybrid — before you run a single assessment.

Fix those two early, and the downstream phases flow. Get them wrong, and you’re looking at nine to twelve months, not six.

My Perspective

I’ve implemented ISO 27001 in enough environments — from government to financial services to cloud SaaS — to have strong opinions about where programs succeed and where they fail. The gap assessment is usually where the outcome is determined.

The organizations that complete certification on schedule are rarely the ones with the most mature controls. They’re the ones that knew exactly what they were missing before they started. They used the gap assessment to make hard sequencing decisions early, to socialize realistic expectations with leadership, and to protect their audit investment by entering Stage 1 with evidence, not hope.

The controls that most consistently trip up organizations starting from scratch — the ones I watch most closely on a gap assessment — are the Statement of Applicability, periodic access reviews (quarterly is the recommended minimum; most organizations have never done one), supplier security assessments with IS contract language, tested incident response (not just a plan that lives in a SharePoint nobody reads), and the four 2022-edition controls that are still underestimated: threat intelligence (A.5.7), cloud service security (A.5.23), ICT readiness for business continuity (A.5.30), and monitoring activities (A.8.16). These aren’t obscure — they’re just new enough that organizations haven’t built them into their default ISMS architecture yet.

ISO 27001 certification is not a compliance trophy. Done properly, it’s operational infrastructure — the difference between a security program that responds to incidents because it has to and one that prevents them because it was designed to.

The gap assessment is how you know which one you’re building.

DISC InfoSec is a boutique cybersecurity and AI governance consultancy. Hugh Deura serves as lead implementer and internal auditor for ISO 27001 and ISO 42001 engagements. If you’re evaluating your organization’s readiness for ISO 27001 certification, we offer a structured gap assessment engagement that delivers a prioritized remediation roadmap, an honest timeline, and a plain-English brief for leadership.

Connect or reach out at deurainfosec.com

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: isms, ISO 27001 2022, ISO 27001 gap assessment

https://www.helpnetsecurity.com/2026/06/16/delinea-securing-machine-identities-and-agentic-ai/

Jun 16 2026

The New Identity Perimeter: Machines, Agents, and the Trust Problem

Category: AI,AI Governance,AI Governance Enforcement,AI Guardrails,AI Risk,Information Security — disc7 @ 10:40 am

The New Identity Perimeter: Machines, Agents, and the Trust Problem

Identity security is entering a fundamentally new phase — one where protecting access is no longer just about people, but about the full ecosystem of entities, human and non-human, that touch enterprise data and systems. Delinea CPO Phil Calvin, in conversation with OWASP contributor Chris Hughes, frames this shift as the defining security challenge of the current era: the question is no longer simply “who is this person?” but “what entity is accessing my environment, and should it be trusted?”

For decades, identity and access management was human-centric — authenticate the right person, grant the right role, audit the right session. But machines, APIs, bots, and now AI agents have become digital actors in their own right: they authenticate, access sensitive data, execute workflows, and make decisions, often at speeds and scales that no human workforce can match. The identity model that worked for employee directories was never designed for this. The implicit assumption that identity equals person is now a dangerous architectural debt.

For every human identity in a modern enterprise, there may be dozens of machine identities — automatically created, rarely tracked, and frequently left behind when projects end or architectures change. Cloud-native environments, microservices, and CI/CD pipelines have turned this into an explosion of unmanaged credentials. Attackers have adapted accordingly: compromised machine credentials have become one of the most reliable initial access vectors in major breaches precisely because no one is watching them.

Agentic AI has accelerated this problem dramatically. Unlike prior-generation AI that produced text or recommendations, agentic systems give LLMs the ability to take real actions — logging into systems, calling APIs, executing workflows, and making decisions about data and security operations. Each agent carries credentials, tokens, and entitlements. Each is, in identity security terms, a non-human principal with real privileges. The velocity is what makes this dangerous: a single employee deploying an AI agent could unknowingly multiply their effective access tenfold, spawning a cluster of high-privilege entities operating semi-autonomously under their account.

Visibility remains the hardest unsolved problem. Most enterprises today cannot confidently answer how many non-human identities exist in their environment, what privileges those identities hold, which are tied to AI agents or automation frameworks, or where credentials are embedded in code or stored insecurely. Discovery — continuous, cross-environment inventory of every key, token, secret, and agent — is the mandatory first step before governance is even possible. You cannot right-size what you cannot see.

Governance of machine entitlements is uniquely difficult because, unlike humans, machines don’t push back against excessive access. Engineers over-provision credentials to ensure workflows don’t break, and those permissions persist indefinitely. As AI agents acquire greater autonomy, this over-privilege problem compounds. The corrective posture is least privilege enforced through automation: remove standing credentials, rotate secrets continuously, vault sensitive machine secrets, and integrate policy enforcement directly into deployment pipelines — not as a retrofit, but as a native control.

AI occupies a dual role in this threat landscape. On the offensive side, adversaries are already using AI to automate reconnaissance, craft convincing phishing campaigns, and exploit leaked credentials faster than human security teams can respond. On the defensive side, AI can enhance visibility into identity behavior, detect anomalous privilege patterns, and accelerate response. The practical implication is that defenders must use AI to govern AI — building intelligence into the identity security lifecycle itself, not just deploying it as a perimeter tool.

My Perspective as an Agentic AI Expert

Calvin’s framing is directionally correct and overdue, but I’d argue it still understates the severity of what’s coming. The identity sprawl problem he describes with service accounts is a known, relatively static challenge. Agentic AI identity sprawl is qualitatively different — it’s dynamic. Agents spin up sub-agents, delegate tasks across tool chains, and accumulate context and credentials across sessions in ways that no PAM (Privileged Access Management) tool designed for human workflows was architected to handle.

The piece’s five-step framework (discover, classify, least privilege, automate, monitor) is sound hygiene, but it treats agentic identity as an extension of the existing machine identity problem. I’d push back on that. An agentic AI system operating inside an enterprise isn’t just another service account — it’s a decision-making principal that may legitimately need broad access to do its job, and the challenge is ensuring that breadth of access is contextually constrained and auditable in real time, not just provisioned conservatively at deployment.

From an AI governance standpoint — which is where ISO 42001 and the NIST AI RMF come in — what’s missing from this conversation is the accountability layer. Least privilege and credential rotation are necessary but not sufficient. Organizations also need to be able to answer: What decision did this agent make? On whose authority? With what information? And can that be audited after the fact? That’s not a PAM problem. That’s an AI governance problem. The two disciplines need to converge, and most enterprises are running them in completely separate silos with no shared control framework.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: The New Identity Perimeter

The AI Governance Quick-Start: Defensible in 10 Days, Not 4 Quarters

Jun 15 2026

Securing the Agentic Enterprise: Where AI Autonomy Meets ISO 42001 and the EU AI Act

Category: AI,AI Guardrails,AI Risk,Information Security — disc7 @ 9:17 am

Architecting Secure Enterprise AI Agents: A Practitioner’s Guide to Building AI That Earns Trust

The enterprise AI landscape has fundamentally shifted. We’ve moved beyond chatbots that answer questions to autonomous agents that perceive context, reason over goals, and take action through real tools and services. But here’s the uncomfortable truth that IBM’s recent guide (verified by Anthropic) makes crystal clear: the way we build these agents cannot be the way we built traditional software. The old playbook doesn’t just need updating—it needs rethinking from the ground up. As someone who works in AI governance daily, I find this distinction isn’t academic; it’s the difference between an agent that creates value and one that creates liability.

The core problem is what the guide calls the shift “from deterministic to probabilistic.” Traditional software follows predictable paths: the same input produces the same output every time. AI agents don’t work this way. Feed an identical prompt to the same agent twice and you may get two different responses. This single characteristic cascades into everything else. You can’t simply deploy an agent to production after it passes staging tests, because “passing” is no longer a binary state. The guide introduces a powerful reframing here: we’re moving from “code-first to evaluation-first.” A technically perfect implementation can produce terrible agent behavior, while a messy prompt might work beautifully. Success depends not on clean code but on systematic measurement of what the agent actually does.

To address this, the guide proposes the Agent Development Lifecycle (ADLC)—essentially DevSecOps reimagined for the agentic era. It organizes work into six interconnected phases: Plan, Code and Build, Test and Release, Deploy, Operate, and Monitor. What makes it different from traditional DevSecOps are two new “inner loops.” The Experimentation Loop sits between Build and Test, using evaluation frameworks to improve agent behavior during development. The Runtime Optimization Loop runs continuously in production, balancing agent quality against operational cost. These loops exist because agents inject “stochastic control logic” into systems that previously ran on rigid, predictable rules.

So how do you actually build a secure AI agent? Start with the Plan phase by defining a narrow, measurable use case and establishing your KPIs before writing a single line of code—accuracy, latency, trust scores, safety thresholds. Crucially, decide your “acceptable agency”: exactly what the agent can and cannot do autonomously. In the Code and Build phase, implement your prompts, memory strategies, and orchestration logic while treating every integration as a tool exposed through the Model Context Protocol (MCP). Keep these tools least-privilege, versioned, and well-documented. Issue every agent its own identity so that every action is traceable and auditable, and instrument observability hooks from the start to capture reasoning traces, tool calls, and outputs.

Security cannot be an afterthought bolted on at the end—it must be woven into the architecture. The guide emphasizes sandboxing as a foundational control, not an optional feature. Because agents often execute dynamically generated code and interact with diverse tools, an unconstrained agent that gets compromised can reach far beyond its intended scope. Run agents inside lightweight isolation frameworks (Firecracker, gVisor, container security profiles) to enforce hard boundaries and prevent lateral movement. Complement this with an MCP Gateway that acts as a single, policy-enforced entry point: it handles authentication, authorization, rate limiting, and applies policy-as-code rules across all your agents and tools. This layered approach—infrastructure isolation plus gateway governance—creates genuine defense in depth.

The Test phase demands behavioral validation, not just traditional unit tests. Run structured evaluations against benchmarks, measure governance metrics like hallucination rate and bias, and deploy guardrails throughout the lifecycle. Use techniques like “LLM-as-a-Judge” alongside human-in-the-loop review, and perform red teaming to surface vulnerabilities before they reach production. Only after an agent passes these gates should it be certified in a governed catalog. During Deployment, roll out progressively, design for resilience against outages and cyberattacks, and always include a kill-switch to disable the agent in emergencies. Then in Operate and Monitor, track real-time accuracy, latency, and cost while watching for the unique threats agents face: memory poisoning, tool misuse, and “intent breaking” where attackers hijack an agent’s purpose through manipulated prompts.

Governance ties the entire framework together and is where my own field intersects most directly with this work. The guide advocates for a governed catalog that records each agent’s purpose, owners, capabilities, risk posture, and data-handling policies—with immutable audit trails linking evaluation results, red team reports, and approvals. This isn’t bureaucracy for its own sake. As agents proliferate, organizations face “agent sprawl” and “shadow AI,” where ungoverned agents drift from policy undetected. The catalog, combined with rigorous version control and Software Bills of Materials (SBOMs) for tools, prompts, and code, gives enterprises the evidence trail they need to satisfy auditors and regulators. Every release should pass through prerelease checks, promotion gates, and runtime attestations.

The real-world examples in the guide validate the framework’s necessity. A healthcare payer maintaining HIPAA compliance had to synthesize ground-truth data because they couldn’t access historical records, then deploy a fully managed compliant stack rather than standard SaaS. A telecommunications firm struggled to track “tens of agent variants” without proper experiment tracking. A major bank recognized that while traditional security protects source code, AI agents require security across data access, embeddings, prompts, and RAG pipelines—with specialized scanning for prompt injection, jailbreaks, and model poisoning. These aren’t hypothetical risks; they’re the lived experience of enterprises deploying agents at scale in regulated industries today.

My perspective: Having spent considerable time in AI governance and ISO 42001 implementation, I believe this guide captures something the industry has been slow to accept: agentic AI is not a more powerful version of traditional automation—it’s a different category of system that demands a different discipline. What strikes me most is how naturally the ADLC aligns with emerging governance standards like ISO 42001 and the EU AI Act. The emphasis on acceptable agency, human oversight, auditability, and continuous monitoring isn’t just good engineering; it’s the operational backbone of regulatory compliance. My one caution is that frameworks like this can intimidate organizations into either over-engineering or analysis paralysis. The guide’s own advice—find the simplest solution, sometimes don’t build an agent at all, start with single-agent systems—is the wisest counsel in the entire document. The winning formula isn’t maximum autonomy; it’s the right amount of autonomy, tightly governed, continuously evaluated, and always reversible. Build agents that earn trust through transparency and control, and the business value follows. Build them for sophistication alone, and you’re constructing tomorrow’s compliance nightmare.

DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.

AI Vulnerability Scorecard: Discover Your AI Attack Surface Before Attackers Do

Your Shadow AI Problem Has a Name-And Now It Has a Score

Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.

AIMS and Data Governance – Managing data responsibly isn’t just good practice—it’s a legal and ethical imperative

Tags: Agentic AI

The AI Governance Quick-Start: Defensible in 10 Days, Not 4 Quarters

Jun 11 2026

Regulatory Relief Is Not Risk Relief: The EU AI Act Delay Trap

Category: AI,AI Risk — disc7 @ 8:18 am

The Delay Trap: Why the EU AI Act Postponement Is the Most Dangerous Gift Your Compliance Program Ever Received

Brussels just handed enterprises sixteen extra months. Most of them are about to spend it accumulating governance debt.

On May 7, 2026, EU legislators reached a provisional agreement on the Digital Omnibus on AI — the first substantive amendment to the AI Act since its adoption. The headline: obligations for standalone high-risk AI systems under Annex III, originally biting on August 2, 2026, are deferred to December 2, 2027. High-risk AI embedded in regulated products under Annex I slips further, to August 2, 2028.

Across boardrooms, you could hear the exhale. Budget lines earmarked for AI Act readiness are already being quietly reallocated. Steering committees that met biweekly are moving to quarterly. “We have until the end of 2027” is becoming the most repeated sentence in European compliance.

It’s also the most dangerous one.

The deadline moved. Nothing else did.

Here’s what the delay did not change: your AI footprint. The recruitment screening model your HR team piloted last quarter. The credit decisioning logic your fintech partner embedded in your onboarding flow. The agentic workflows your engineering org is wiring into production right now, this week, without waiting for Brussels to finish its paperwork.

The AI Act’s timeline was political. Your risk accumulation is operational. Those two clocks were never synchronized, and the Omnibus just desynchronized them further. Every month between now and December 2027, your organization will deploy more AI, embed it deeper into consequential decisions, and entangle it with more vendors — while the regulatory pressure that was forcing executive attention quietly deflates.

I’ve spent two decades watching organizations respond to compliance deadlines, from SOX to GDPR to ISO certification cycles. The pattern is depressingly consistent: a moved deadline doesn’t extend the runway. It deletes the urgency, the program decays, and eighteen months later the organization restarts from a worse position than where it paused — because the environment kept getting more complex while the program stood still.

That’s governance debt with a compounding interest rate. And the AI version compounds faster than anything we’ve seen, because AI adoption doesn’t pause when your governance program does.

Three reasons “we’ll restart in 2027” is a fiction

First, the delay isn’t even law yet. The May 7 agreement is provisional. Formal adoption and publication in the Official Journal are still pending. The April trilogue round collapsed before this one succeeded, which tells you how fragile the politics are. Until the amendment is in the Official Journal, August 2, 2026 remains the legally operative date — and several obligations, including transparency requirements and enforcement structures, were never part of the deferral conversation at all. Organizations planning against a deadline that hasn’t been enacted are practicing compliance by press release.

Second, the EU was never your only regulator. Colorado’s AI Act, the expanding patchwork of US state AI legislation, sector regulators sharpening their AI expectations, and — most immediately — your customers’ procurement teams. Enterprise buyers are not waiting for December 2027 to ask how you govern AI. They’re asking now, in security questionnaires, in vendor risk assessments, in contract language. I watched this dynamic play out firsthand taking a client through ISO 42001 certification: the commercial pressure to demonstrate AI governance arrived well ahead of any regulatory enforcement date. The market is enforcing faster than the regulators.

Third, the legislators themselves told you why they delayed. The deferral exists because harmonised standards, notified bodies, and compliance tooling weren’t ready — not because the obligations got lighter. The requirements in Articles 9 through 17 are coming intact: risk management systems, data governance, technical documentation, logging, human oversight, accuracy and robustness. Sixteen months is not generous for building those capabilities from a standing start. It’s barely adequate for organizations that keep moving. For organizations that pause and restart in mid-2027? It’s a guaranteed fire drill, executed against finalized standards, with every consultancy and notified body in Europe simultaneously overbooked.

What the sixteen months are actually for

The organizations that will look smart in December 2027 are treating this window as exactly what the legislators intended: time to build properly instead of compliance theater under deadline pressure.

That means doing the unglamorous foundational work now. Inventory your AI systems — including the shadow AI your business units deployed without telling anyone, and the AI capabilities your vendors switched on inside products you already license. Classify against Annex III honestly, not optimistically. Stand up the risk management and data governance machinery that Article 9 and Article 10 will demand, because those capabilities take quarters to mature, not weeks.

And anchor it in a management system, not a project plan. This is where ISO 42001 earns its relevance. A certifiable AI management system gives you a regulation-agnostic backbone: the same governance infrastructure satisfies EU AI Act obligations, Colorado’s requirements, NIST AI RMF alignment, and the procurement questionnaires landing in your inbox this quarter. Projects end when deadlines move. Management systems persist because they’re wired into how the organization operates. That structural difference is precisely what separates the companies that will coast through December 2027 from the ones that will panic through it.

The Digital Omnibus came with an explicit expectation attached: implementation efforts should already be underway. That wasn’t diplomatic filler. It was the legislators telling you how they’ll view organizations that show up in late 2027 with nothing built.

The question for your next leadership meeting

Don’t ask “when is the deadline now?” Ask: “What did we deploy this quarter that we couldn’t explain to a regulator, a customer, or a courtroom?”

If the honest answer is “we’re not sure,” the EU just gave you sixteen months to find out. Spend them like the gift they are — or discover in 2027 that the delay trap was never about the deadline at all.

DISC InfoSec helps organizations build AI governance programs that survive deadline changes — ISO 42001 implementation, EU AI Act readiness, and NIST AI RMF alignment from a practitioner who has taken a client through certification, not just talked about it. Start with our free EU AI Act gap assessment at deurainfosec.com.

DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.