All insights
AI security & compliance6 min read

DSPM and AI security: what enterprises get wrong about data posture

Data security posture management (DSPM) is the control that decides whether enterprise AI is safe to switch on. What DSPM does, how it maps to Copilot and agents, and how to sequence it in Australia.

By FORTE/CYBERx AdvisoryReviewed by FORTE/CYBERx Advisory18 August 2026

What DSPM actually is

Data security posture management is the discipline of knowing, continuously, where your sensitive data lives, who can reach it, how it is protected and how that exposure is changing. It spans cloud storage, SaaS platforms, collaboration tools, databases and the copies that quietly accumulate around them.

The distinction that matters is between posture and perimeter. Traditional controls ask whether an attacker can get in. DSPM asks a harder question: given the access already granted inside the organisation, what could legitimately be retrieved today, and by whom? For years that question was academic, because nobody had the time to traverse every permission on every file. AI answers it in a second and a half.

Why AI turned a slow problem into an urgent one

Enterprise AI assistants retrieve on behalf of the user. Microsoft 365 Copilot, to take the most common example, honours existing permissions — it does not grant new access. That sounds reassuring until you accept what it implies: every over-permissioned site, every "share with everyone in the organisation" link created in 2019, every HR folder with inherited access is now reachable through a natural-language question.

We have never seen AI create an oversharing problem. We have repeatedly seen it surface one. The salary review file that was technically open to 4,000 people was safe only because nobody knew the filename. Retrieval removes that protection permanently.

Agents raise the stakes further. An assistant that reads and answers is one exposure profile; an agent that reads, decides and acts across systems is another. The blast radius of a posture failure is no longer a disclosure, it is an action taken on bad or unauthorised data.

The four capabilities that make DSPM real

Discovery — find the data, including the copies. Sanctioned repositories are the easy part. The exposure usually sits in exported spreadsheets, personal drives, legacy team sites, test environments seeded with production data, and SaaS tools procured by a business unit three years ago.

Classification — decide what each dataset is. Personal information, health information, payment data, client confidential material, board and legal privileged content, and intellectual property each carry different obligations under the Privacy Act and under client contracts. Classification is what turns a file inventory into a risk register.

Access and exposure analysis — establish the effective permission, not the intended one. Nested groups, inherited site permissions, anonymous links and guest accounts routinely combine into access nobody designed. This is the analysis that predicts what an AI assistant will retrieve.

Enforcement and monitoring — labels that drive encryption and handling, retention that removes data you no longer need, alerts on new high-risk exposure, and controls that stop labelled content flowing into unapproved AI destinations. Discovery without enforcement is a report that ages badly.

Where organisations get it wrong

The most common failure is buying a tool and calling it a programme. A DSPM platform will produce an impressive first scan, and then nothing changes, because no one owns remediation and no business unit has agreed to lose access to anything.

The second is over-classification. A taxonomy with eleven labels and four sub-levels is applied inconsistently on day one and abandoned by quarter two. Three or four labels that people can apply without a manual will beat a perfect scheme nobody uses.

The third is treating this as purely technical. Deciding that a folder should no longer be open to the whole organisation is a business decision with an owner, an objection and a workaround to design. The technology is rarely the constraint.

The fourth is sequencing. Broad AI enablement first, posture work second, is the order that produces the incident. It is also, in our experience, the most common plan on the table when we are brought in.

Sequencing posture work against an AI rollout

Before pilot — inventory the repositories the assistant will index, run discovery and classification across them, and fix the top exposure: organisation-wide sharing links, stale guest access, and sites containing regulated data with permissive membership. Restrict the pilot to a scoped set of sites rather than the whole tenant.

During pilot — instrument it. Monitor what is actually retrieved, watch for sensitive-classification hits, and run a deliberate red-team question set: ask the assistant the things a curious employee would ask about salaries, redundancies, acquisitions and disciplinary matters. The answers are your remediation backlog.

Before broad rollout — enforce. Apply sensitivity labels with encryption on the highest-risk classes, exclude designated content from indexing, close the default-open sharing behaviours at tenant level, and confirm retention is deleting what should no longer exist.

After rollout — treat posture as continuous. New sites, new SaaS tools, new agents and new integrations change the exposure surface weekly. A quarterly review with an owner and a remediation queue is the minimum that holds.

Apply this to your organisation

Want this assessed against your environment?

Send us the specifics and a senior advisor will respond within one business day.

Native secure submission. Your details are never sold or shared.

How this maps to the frameworks you are measured against

ISO/IEC 27001 already requires an inventory of information assets, classification, and access control proportionate to risk. DSPM is largely the evidence layer for controls you have committed to, which is why certified organisations often find posture work easier to fund than they expect.

ISO/IEC 42001 adds the AI management system view: data used by AI systems must be governed, with provenance, quality and appropriateness recorded. An AI system that retrieves from an unclassified corpus cannot satisfy that requirement in any defensible way.

The Privacy Act and the OAIC's expectations on reasonable security steps sit underneath both, and the ACSC's guidance on engaging with artificial intelligence is explicit that organisations should understand and control the data an AI system can access before deploying it.

The metrics worth reporting to a board

Percentage of in-scope repositories discovered and classified. Number of items with organisation-wide or anonymous access that hold regulated or confidential data — and the trend, which matters more than the number. Mean time to remediate a new high-risk exposure. Percentage of AI-indexed content that carries a sensitivity label. Number of AI systems and agents with a documented data scope and owner.

Avoid volume metrics. "We scanned 40 million files" tells a board nothing. "Organisation-wide access to files containing personal information fell from 12,400 items to 900, and new exposures are now closed within five days" is a decision-grade statement.

A pragmatic 60-day start

Days 1–15 — scope. Name the repositories in and out of scope, appoint a data owner per major repository, and agree a three-label classification scheme. Run discovery on the two highest-risk repositories only.

Days 16–30 — expose the truth. Produce the effective-access report for regulated and confidential data, and run the red-team question set against a scoped AI pilot. Present both to the executive together; the pairing is what unlocks the remediation mandate.

Days 31–45 — remediate the top tier. Close organisation-wide links on sensitive content, remove stale guest and departed-user access, and label the highest-risk classes with encryption enforced.

Days 46–60 — make it durable. Turn on monitoring for new high-risk exposure, define the quarterly posture review with a named owner, and write the rule that no new AI system or agent goes live without a documented data scope. That rule is worth more than the first scan.

The uncomfortable conclusion

Most enterprises we assess are not blocked from AI by model risk, prompt injection or regulation. They are blocked by fifteen years of accumulated permission debt that nobody had a reason to repay until a search box made it retrievable.

That is genuinely good news. Permission debt is finite, measurable and fixable, and the work has value whether or not the AI programme proceeds. It is the rare security investment where the compliance case, the AI enablement case and the plain operational case all point in the same direction.

Sources and further reading

This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.

Related reading

Start a useful conversation

Talk to a senior advisor

Tell us the decision, constraint or opportunity. A senior operator responds within one business day.

Native secure submission. No embedded HubSpot branding.