The AI Paradigm Shift: Asset Security and Where AI Meets Your Data in CISSP Domain 2
Intro
The first article in this series covered Domain 1: governance, policy, and the risk structures that decide who’s accountable for AI. That’s the part where you write the rules. Domain 2 is where the rules meet the assets.
Asset Security is about the things you actually own. You can’t protect an asset you haven’t named; you can’t apply the right control until you know how sensitive it is, and you can’t claim it’s destroyed unless you can prove it. AI doesn’t change that logic. It changes the inventory. Training datasets, prompt histories, fine-tuning inputs, and model weights are now corporate assets that carry real value and real exposure, and likely postdate many asset registers. Fine-tuning inputs are the proprietary examples a company supplies to adapt a pre-trained model to its own work, the tagged support transcripts or annotated documents that teach a general model a specific domain.
ISC2’s Exam Guidance for Artificial Intelligence (April 2, 2026) points in the same direction. The guidance maps AI security into the existing eight domains, and for Domain 2, that means extending the asset-security work you already do to this new inventory. Part 1 walked through the mapping. (See AI Security for the CISSP: What’s Changed.)
Here’s the shift in one line.
Classifying AI Assets
You can’t protect what you can’t see. Classic asset security grew up around structured databases, physical media, and discrete files, things with an obvious shape and an obvious owner. AI assets break that mold, and the value sits in unexpected places.
Foundation models are commoditizing fast. Capable base models are cheap or free to get, many with downloadable (open) weights, so the base model itself is rarely where a company’s advantage lives. That advantage sits in the data you fed the model and the resulting weights. If a competitor walks off with your refined training set or your final model weights, the damage is immediate, because they get the full benefit of your work without paying to build it.
That leads to the rule to anchor on, whether you’re studying or doing the work: classify AI assets by the impact of their compromise, not by their file format or where they happen to sit. A 4 GB weights file and a spreadsheet look the same to a storage system. They’re nowhere close in value.
One complication: AI assets are hard to value precisely. A model’s capabilities can emerge during training in ways the team didn’t plan for, so a standard benchmark won’t always tell you what the thing is really worth, or what you’d actually lose. When the value is fuzzy, classify for the downside. Ask what a competitor or a regulator could do with the asset if it walked, and price the protection against that.
Who Owns What: Data Roles in an AI Pipeline
Most asset-security failures in AI aren’t exotic. They come from blurred roles. In a machine learning pipeline, the people who own the data, the people who run the infrastructure, and the systems that process the records all start to overlap, and accountability quietly evaporates. Keeping these roles straight matters as much in production as it does in study.
Data Owner. A senior leader, accountable for the asset. The Owner sets the classification, approves access, and authorizes any corporate data going into a training pipeline. Accountability stops here and can’t be handed off to a technician.
Data Custodian. The technical role that implements what the Owner approved: backups, encryption keys, access lists, the hosting environment.
Data Controller. A privacy role under GDPR. The Controller decides the purpose and lawful basis for processing personal data and makes sure training inputs comply with privacy law.
Data Processor. Processes personal data only on the Controller’s instructions. A third-party AI summarization or translation API is the textbook example.
Data Subject. The person whose data is being processed or trained on.
User. The employee who actually operates the system to get work done.
It almost always plays out the same way. A data scientist or DBA, acting as a Custodian, uploads a corporate dataset to a public AI service to get a quick result, and nobody cleared it with the Owner. Outside the company’s control, that service might store the data, keep it indefinitely, or train its models on it, and any of those outcomes leaks intellectual property and creates third-party privacy risk. Only the Owner has the authority to accept that risk, and a Custodian who makes the call alone has broken the asset-security policy. The GDPR definitions of controller and processor exist to keep exactly that line from blurring.
The fix is administrative, not technical. Separation of duties so the engineers who train models can’t also push them to production or rewrite access controls. Job rotation and mandatory vacations so quiet tampering, poisoned data, or unauthorized parameter changes have a chance to surface.
Protecting Data in Three States
Every asset lives in one of three states, and each one needs a different control. Apply the wrong one, and you either leave a hole or break the system.
