NIST’s National Vulnerability Database (NVD) backlog mushroomed from 13,000 unprocessed security vulnerabilities in February 2024 to more than 27,000 by the end of 2025, “undermining the NVD’s utility and public trust,” according to an inspector general report.

The Record from Recorded Future News – ​Read More

Part 4 of a series on creating information security policies.

Visibility before Protection

Organizations often invest heavily in cybersecurity tools: endpoint protection, firewalls, SIEM platforms, MFA, cloud security solutions, and threat detection services. Unfortunately, many security incidents still come down to a surprisingly simple problem: organizations do not fully understand what they own or where their sensitive data resides.

Before an organization can protect its environment, it first needs visibility.

(Don’t miss the Template at the end)

This is why asset management and data classification are foundational components of modern information security programs. They are not simply administrative exercises or compliance checkboxes. They are core security capabilities that directly influence risk reduction, incident response, governance, and regulatory compliance.

An aside: A good description of a Critical resource is something that is a) public-facing and b) contains important/sensitive/etc. data. On a quick search I can’t find the source for this description, but it’s something that Eric Cole said. And he’s also described it as “any asset, data, or system that is essential to the survival and primary mission of an organization or individual.” (update: I just read today, right before publishing this article, the announcement that Eric Cole passed away recently).

Many major frameworks and standards place significant emphasis on these areas. The National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) highlights asset management as part of the Identify function. International Organization for Standardization 27001 requires organizations to inventory information assets and establish classification procedures. American Institute of Certified Public Accountants SOC 2 evaluations frequently assess inventory management, logical access, and data handling practices. Regulations such as European Union GDPR also depend heavily on organizations understanding what personal data they possess and how it is protected.

At a practical level, the principle is simple: you cannot secure assets or information you do not know exist. Keeping track of assets became incredibly difficult and expensive when APIs came on the scene many years ago. Now, with AI agents, it’s become even more difficult and expensive!

Visibility Before Protection

A common challenge within organizations is incomplete visibility into the environment. Security teams are often responsible for protecting hundreds or thousands of systems, applications, devices, cloud services, and data repositories spread across departments and business units.

In time, environments become messy.

A cloud storage bucket created for a temporary project remains active years later. A former employee’s account is never fully disabled. An old server continues operating in a forgotten network segment. Sensitive spreadsheets are downloaded locally and shared outside approved collaboration platforms. Shadow IT solutions appear without security review.

These overlooked assets become attractive targets for attackers precisely because they are overlooked.

Threat actors are increasingly skilled at identifying unmanaged or weakly monitored systems. In many breaches, attackers do not break through the organization’s strongest defenses; they exploit forgotten assets, stale accounts, unpatched systems, or poorly governed data repositories (aka, shadow and zombie resources).

This is why asset management is FAR MORE than an IT inventory exercise. It’s a foundational security control.

The NIST CSF emphasizes this concept directly. Within the Identify function, organizations are encouraged to understand the assets, systems, data, and capabilities that support business operations. Without that visibility, risk assessments become incomplete and security priorities become reactive rather than strategic.

Similarly, ISO 27001 Annex A includes controls related to asset inventories, ownership responsibilities, acceptable use, and information classification. The message across these frameworks is consistent: visibility enables security.

Effective asset management programs typically include several core elements:

• Asset inventories for hardware, software, cloud services, and data repositories
• Defined asset ownership
• Lifecycle tracking
• Regular inventory reviews
• Configuration management
• Monitoring for unauthorized or unmanaged assets

Ownership matters just as much as visibility. Every asset needs an accountable owner responsible for its maintenance, access approvals, and security requirements. Assets without ownership become assets without oversight.

Why Data Classification Simplifies Security

Once organizations understand what assets they possess, the next challenge is understanding the sensitivity of the information stored within them.

Not all data carries the same level of risk.

A public marketing brochure does not require the same protections as employee records, customer financial data, security architecture diagrams, or intellectual property. Without classification, organizations struggle to apply security controls consistently.

This creates two common problems.

1) Orgs may overprotect low-risk information, creating unnecessary friction and operational complexity (not to mention extra cost!).

2) They may underprotect highly sensitive information because they fail to recognize its importance. (the extra cost in #1 may lead to underfunding in #2)

Data classification solves this by creating context.

A well-designed classification program helps employees and security teams quickly understand how information should be handled, stored, transmitted, and protected. It also improves consistency across departments and technologies.

One of the easiest classification structures is something like this:

Public

Information approved for public release.

Examples include:

• Website content
• Press releases
• Marketing materials

While public data may not require strict confidentiality protections, organizations still need to preserve integrity and accuracy.

Internal

Information intended for internal organizational use.

Examples include:

• Internal procedures
• Organizational charts
• Operational documentation
• Internal communications

This information should generally remain accessible only to authorized employees and contractors.

Confidential

Sensitive information is that info almost certain to harm the organization, employees, customers, or partners if disclosed improperly.

Examples include:

• Customer records
• Financial information
• Employee data
• Authentication credentials
• Security configurations
• Intellectual property

Confidential information typically requires stronger access controls, encryption, monitoring, and restricted sharing practices.

Data classification also directly supports regulatory compliance efforts.

Under GDPR, organizations are expected to understand what personal data they process and implement safeguards appropriate to the risk. Similarly, SOC 2 reports examine how organizations identify and protect sensitive information within their environments. This report contains deeply technical information and internally revealing information; it’s best to keep it closely guarded.

Classification also becomes incredibly valuable during incident response.

When a security event occurs, one of the first questions leadership asks is: “What data was affected?”

Organizations with mature classification programs can answer this much faster. They can determine whether exposed information was public, internal, or confidential, which directly influences response actions, legal obligations, customer notifications, and business impact assessments.

Handling Requirements Matter

Classification labels alone are not enough.

The real value comes from defining handling requirements that guide employee behavior and technical controls throughout the information lifecycle.

An effective Asset & Data Classification Policy needs to establish clear expectations for:

• Storage
• Transmission
• Retention
• Disposal
• Access control
• Encryption
• Monitoring

For example, confidential data may require:

• Encryption at rest and in transit
• MFA-protected access
• Restricted sharing permissions
• Approved storage platforms
• Logging and monitoring
• Secure disposal procedures

Internal information may require simpler protections such as authenticated access and approved collaboration platforms.

The objective? consistency.

Don’t make employees guess how sensitive information should be handled. Policies and classifications should make expectations clear and actionable. Make sure the policies are a) centrally located and b) easily accessible.

This is more important in hybrid work environments where employees routinely access data from cloud platforms, remote locations, mobile devices, and third-party applications.

Building Security from the Ground Up

One of the most important lessons in governance, risk, and compliance is that mature security programs are built on strong fundamentals.

Advanced detection tools and sophisticated security technologies are valuable, but they cannot compensate for poor visibility and unmanaged data risks.

Organizations that struggle with asset management and data classification often experience:

• Incomplete risk assessments
• Weak access governance
• Regulatory compliance gaps
• Inefficient incident response
• Increased likelihood of data exposure

Conversely, organizations with strong visibility and classification practices are better positioned to prioritize security investments, enforce consistent controls, and respond effectively when incidents occur.

The Closing

The reality: many security failures aren’t caused solely by sophisticated attacks. Many occur because organizations lacked awareness of what they owned, where critical information resided, and/or how sensitive data should have been protected.

Before organizations can strengthen defenses, deploy advanced tools, or improve detection capabilities, they must first answer two foundational questions:

What do we have?

And

How important is it?

 

TEMPLATE (make it your own – adapt as needed!)

(NOTE: As you see below, the policy is not very detailed. Policies are meant to be overarching and not readily changed, though they need to be reviewed regularly. People often conflate Procedures with Policies. In common parlance, it’s fine to talk of changing policies and procedures, and often the two are combined – which is just fine. But in actual terminology, the two are separate. For SMBs, life is probably easier putting the Policies and Procedures together to review regularly (typically minimum of once annually for ISO 27001). But for large orgs, enterprises, and educational institutions, it ‘s often best to separate the two. Because a Policy is a guiding document, you don’t want to have to change the principles and guidance and primary directives often at all.)

Asset & Data Classification Policy

Policy Overview

Policy Name

Asset & Data Classification Policy

Policy Owner

[Department / Security Team / Governance Team]

Policy Approver

[Executive Leadership / CISO / CIO]

Effective Date

[Insert Date]

Review Cycle

This policy shall be reviewed annually or upon significant organizational, regulatory, or technological changes.

Related Standards & Frameworks

• ISO/IEC 27001
• NIST Cybersecurity Framework (CSF)
• SOC 2 Trust Services Criteria
• GDPR
• Applicable legal, contractual, and regulatory obligations

1. Purpose

The purpose of this policy is to establish requirements for identifying, classifying, handling, and protecting organizational information assets.

This policy is intended to:

• Improve visibility into organizational assets and data
• Support risk management and cybersecurity efforts
• Protect sensitive information from unauthorized access, disclosure, alteration, or destruction
• Support compliance with legal, regulatory, and contractual obligations
• Define consistent security expectations for information handling

2. Scope

This policy applies to:

• All employees
• Contractors
• Third parties with access to organizational assets or information
• All organizational hardware, software, cloud services, applications, and data repositories

This policy applies to information assets regardless of:

• Format
• Location
• Transmission method
• Storage platform

3. Definitions

Asset

Any information, system, device, application, service, or resource that supports business operations.

Examples include:

• Laptops
• Servers
• Cloud platforms
• SaaS applications
• Databases
• User accounts
• Mobile devices
• Documentation

Data Classification

The process of categorizing information based on sensitivity, confidentiality, and business impact.

Asset Owner

An individual or department responsible for the management, security, maintenance, and lifecycle oversight of an asset.

4. Asset Management Requirements

4.1 Asset Ownership

All organizational assets must have an assigned owner.

Asset owners are responsible for:

• Maintaining asset accuracy
• Reviewing access permissions
• Ensuring appropriate security controls
• Supporting lifecycle management
• Reporting unauthorized or unmanaged assets

4.2 Asset Inventory

The organization shall maintain an inventory of information assets, including:

• Hardware
• Software
• Cloud services
• Applications
• Data repositories
• Administrative accounts
• Network-connected devices

Asset inventories shall:

• Be reviewed regularly
• Be updated when assets are added, modified, or removed
• Include ownership information
• Include classification where applicable

5. Data Classification Requirements

Information assets shall be classified according to the following categories:

5.1 Public

Definition

Information approved for public disclosure.

Examples

• Public website content
• Marketing materials
• Published reports
• Press releases

Security Requirements

• Integrity protections should be maintained
• Public disclosure must be authorized

5.2 Internal

Definition

Information intended for internal organizational use only.

Examples

• Internal procedures
• Team communications
• Operational documentation
• Internal business plans

Security Requirements

• Access limited to authorized personnel
• Protected from unauthorized disclosure
• Shared only through approved communication methods

5.3 Confidential

Definition

Sensitive information that could negatively impact the organization, customers, employees, or partners if disclosed improperly.

Examples

• Customer information
• Employee records
• Financial data
• Authentication credentials
• Security configurations
• Intellectual property
• Regulated data

Security Requirements

• Access restricted by business need
• Encryption required during storage and transmission
• Monitoring and logging where applicable
• Sharing limited to authorized individuals and approved platforms

6. Handling Requirements

All classified information must be handled according to organizational security requirements.

6.1 Storage Requirements

Public

May be stored on approved public-facing systems.

Internal

Must be stored on approved organizational platforms with appropriate access controls.

Confidential

Must be stored:

• Using encryption where appropriate
• On approved secure systems
• With restricted access permissions
• In accordance with retention requirements

6.2 Transmission Requirements

Public

May be transmitted through standard approved communication methods.

Internal

Should only be shared through approved organizational communication platforms.

Confidential

Must be transmitted using:

• Encrypted communication methods
• Approved secure file-sharing systems
• Authorized recipients only

6.3 Disposal Requirements

Information assets shall be securely disposed of when no longer required.

Approved disposal methods may include:

• Secure deletion
• Media destruction
• Data wiping
• Physical shredding

Confidential information must be disposed of using secure destruction procedures approved by the organization.

7. Roles & Responsibilities

Security Team

Responsible for:

• Maintaining classification standards
• Supporting policy enforcement
• Monitoring compliance
• Providing guidance

Managers

Responsible for:

• Ensuring employee awareness
• Supporting classification compliance
• Identifying departmental assets

Employees & Users

Responsible for:

• Properly handling information assets
• Following classification requirements
• Reporting security concerns or unauthorized activity

8. Policy Compliance

Violations of this policy may result in:

• Removal of access privileges
• Disciplinary action
• Contractual consequences
• Legal or regulatory penalties where applicable

9. Exceptions

Exceptions to this policy must:

• Be documented
• Include risk justification
• Receive formal approval from authorized leadership or security personnel

10. Policy Review & Maintenance

This policy shall be reviewed:

• Annually
• Following significant security incidents
• Following major infrastructure or regulatory changes

Updates shall be approved through the organization’s governance process.

11. References

• ISO/IEC 27001 Annex A
• NIST Cybersecurity Framework (CSF)
• NIST SP 800-53
• SOC 2 Trust Services Criteria
• General Data Protection Regulation (GDPR)
• Organizational Information Security Policies

Secjuice – ​Read More

Across the frontier labs, the highest prompt injection figures published this spring are Anthropic’s. Point a red-teamer at its newest model in a browser, and the attacker hijacked it 31.5% of the time before safeguards engaged. OpenAI, Google, and Meta never gave security leaders a comparable number to set beside it. That figure looks like a liability. In this comparison, it is the opposite. It’s the one solid piece of ground.

Four frontier labs each shipped a prompt injection disclosure, and no two match. Anthropic put 244 pages and four agentic surfaces on the table on May 28. OpenAI reported one surface, connectors. Google moved the subject out of the model card and into a separate safety framework. Meta shipped no closed-model card at all. The Cross-Vendor Prompt Injection Disclosure Grid below maps what each lab tested, what each one measured, and the four places a side-by-side comparison falls apart.

A prompt injection hides a malicious instruction in something an agent reads, a web page, a document, or a tool result. One planted line can exfiltrate records or fire off actions nobody approved, and these cards are a buyer’s only first-party evidence.

There is no industry standard for measuring any of this, and that is the root of the problem. Carter Rees, VP of AI at Reputation, told VentureBeat that prompt injection breaks the assumption that every legacy tool was built on. “A phrase as innocuous as, ‘ignore previous instructions’ can carry a payload as devastating as a buffer overflow, yet it shares no commonality with known malware signatures.” With no shared signature to scan for, each lab built its own yardstick, and the results do not line up.

Adam Meyers, Senior Vice President of Counter Adversary Operations at CrowdStrike, said that the exposure is now the buyer’s to manage. “As you implement AI, it increases your attack surface, so now you have to be able to protect those AI models against adversary misuse or data poisoning or prompt injection.” CrowdStrike’s own frontline data shows the threat side is not standing still. In its 2026 Financial Services Threat Landscape Report, released in May, the company reported adversaries using AI to compress the time from initial access to impact faster than legacy defenses can respond.

Anthropic measured four surfaces. The numbers swing by an order of magnitude depending on which one you read.

The Opus 4.8 card does what others do not: It breaks prompt injection out by surface, and the spread is the story.

Put the model in a coding environment, and an adaptive attacker from Gray Swan’s Shade tool got through on 7.03% of single attempts with thinking on. Safeguards pulled that to 2.09%.

Move the same class of attack into a browser, the surface behind Claude in Chrome and Claude Cowork, and the floor gives way. Anthropic put professional red-teamers on 129 web environments held out from training and printed every result in Table 5.2.2.4.A on page 81 of the system card. Per-attempt is the share of all injection attempts that got through across 129 environments at 10 tries each. Per-scenario is the harder cut, the share of environments where at least one try landed.

Read down the per-attempt column without safeguards, thinking on, and the raw rate drops with each generation, from Sonnet 4.6 at 50.7% to Opus 4.8 at 31.5%. The lowest in the table, 5.9%, belongs to Mythos Preview, which nobody can buy yet. Turn safeguards on, and Opus 4.8 drops to 0.5%. Turn thinking off and it drops to zero across all 129 environments.

OpenAI measured one surface, with attacks it already knew.

The GPT-5.5 card, published April 23 and updated April 24, handles prompt injection in one place, a single section on robustness to known attacks against connectors. OpenAI reports it as a robustness score where higher is better, the inverse of an attack success rate. GPT-5.5 came in at 0.963, down from 0.998 for GPT-5.4-thinking. That one figure is the whole disclosure.

Anthropic tested four surfaces against an adaptive attacker that rewrites its approach based on what the model does, then ran a one-week bug bounty where red-teamers tried to break the model live. When the coding results came back worse than Opus 4.7, the card said so.

Lay the 0.963 next to the 31.5%, and they look like they belong on a scoreboard. They do not. One is a robustness score against known attacks on one surface. The other is a per-attempt attack success rate across 129 browser environments against an attacker that adapted in real time.

Google and Meta never put the number in the card at all

Google’s Gemini 3 files prompt injection under mitigations, and the launch materials describe stronger resistance with no number attached. The Frontier Safety Framework report does run red teaming, but across its capability domains, and prompt injection is not one of them. No model card, no framework page, no per-surface number a buyer can lift into a risk review.

Meta ships open weights with no closed-model card. Prompt injection defense sits in a separate stack, Purple Llama’s LlamaFirewall. A PromptGuard 2 classifier and an AlignmentCheck auditor, run against the public AgentDojo benchmark and its 97 tasks, cut attack success from 17.6% with no defense to 1.75% combined. Real numbers. They grade the guardrails on a public benchmark, not the model on a deployment surface a security team would recognize.

The Cross-Vendor Prompt Injection Disclosure Grid

The grid below works on any frontier model security teams are weighing. Each row marks a place where the four labs are split. Each split is where a quick comparison breaks. The Anthropic figures come from the Opus 4.8 system card. Everything for the other three comes from each vendor’s published safety documentation.

Dimension	Anthropic, Opus 4.8	OpenAI, GPT-5.5	Google, Gemini 3.x	Meta, Llama stack
Safety document	System card, May 28 2026, 244 pages	System card, April 23 2026, updated April 24	Model card plus a separate Frontier Safety Framework report	No closed-model card. Open weights plus the Purple Llama stack
Injection benchmark or dataset	ART from Gray Swan and UK AISI, the Shade tool, plus an internal browser eval, 129 environments	Internal connectors evaluation, known attacks	None for injection	AgentDojo, 97 tasks
Surfaces with an injection eval	Four. Tool use, coding, computer use, browser	One. Connectors	None published for injection	One. AgentDojo agent tasks
Multi-attempt escalation shown	Yes. ART benchmark at 1, 10, 100. Coding and computer use at 1 and 200	No. A single score	No	No
Headline metric and unit	Attack-success rate. Browser, with thinking, 31.5% raw, 0.5% safeguarded	Robustness score, higher is better. 0.963, down from 0.998 for GPT-5.4-thinking	None published. Increased resistance claimed qualitatively	Attack-success rate on AgentDojo. 17.6% baseline to 1.75% combined
Live external bounty	Yes. One-week live injection bounty with external red-teamers	No injection bounty. Bio bounty only	None found	None found
Regression disclosed	Yes, explicit, with numbers	Number fell 0.998 to 0.963, not framed as a regression	Increased resistance claimed, no numbers	Not applicable

Five factors security teams need to consider now

Anthropic tested four surfaces and printed every number. OpenAI tested one. Google printed no per-surface rate. Meta graded its guardrails, not the model. The four disclosures do not add up to a comparison. These five steps build one.

Pull every agent you have deployed or scoped and tag each by the surface it touches, browser, code, connectors, or desktop. Anthropic’s rate for Opus 4.8 runs 2.09% on coding and 0.5% on browser. A blended number covers neither. Pull the vendor’s published rate for your specific surface. If the vendor never published one, treat it as untested.

Send the Cross-Vendor grid to every vendor under evaluation. A 0.963 connectors score and a 31.5% browser rate were never on one scale. Demand a per-surface attack success rate, raw and safeguarded, with the attacker methodology named. The blank cells are the surfaces with no first-party evidence.

Confirm in writing which number your integration gets. Anthropic’s 0.5% comes from Claude in Chrome and Cowork with the full safeguard stack. On the API, the model ships without them. Do not accept a product number for an API deployment.

Add two clauses to the RFP. The vendor tested with an adaptive attacker that rewrites payloads against the model, and someone outside the company tried to break it. Anthropic ran Gray Swan’s adaptive Shade tool and a one-week paid bounty. OpenAI tested known attacks on one surface. Adversaries do not submit known payloads.

Run your own injection test before any agent ships. Vendor numbers come from vendor environments with vendor system prompts. Your stack has its own prompts, permissions, and data access. Set a pass threshold. Anything above it does not go live.

The bottom line. No standard exists for this yet. A vendor’s number tells you what it chose to measure. Your own red team tells you what you are exposed to.

Security | VentureBeat – ​Read More