If your data catalogue is compromised: containment, credential rotation and rebuild playbook

A compromised data catalogue hands the attacker a ranked index of your sensitive data, the connection credentials its harvesters use to reach every source, and in many deployments the power to change the classification tags that decide who can read what. Catalogues connect to databases, warehouses, lakes, BI tools and SaaS applications to collect metadata, profile columns and draw lineage, so they hold standing non-human access across the data estate. The incident can start with a stolen steward or administrator login, a leaked API token, a compromised harvester you host, or a breach at the catalogue provider. This playbook covers how the compromise shows up, containment at the data sources, checking the integrity of classification and access metadata, rotating every connector credential and rebuilding with narrower trust. It is vendor-neutral and written for data platform, data governance and incident response teams. Normal governance design is covered in the Data Governance and Data Catalogue Security Guide; this page assumes it has already gone wrong.

Key takeaways

• Two incidents in one. Treat it as a confidentiality incident (metadata, samples and source credentials exposed) and an integrity incident (tags, owners and access policies possibly altered) until each is ruled out.
• Contain at the sources, not the console. Disable or rotate the harvester identities in each database, warehouse and SaaS tenant, because the console may still be in hostile hands.
• Classification tags are security controls. Where tags drive masking, row filters or tag-based grants, a downgraded tag is an access grant; diff every tag change in the window against a trusted baseline.
• Profiling samples are data. Column samples, previews and statistics can hold real personal data, so scope them as part of the exposure, not as "only metadata".
• Rebuild read only, per source, with an owner. Reconnect one source at a time with new scoped credentials, sampling off or minimised, and approval for any write-back to the data platform.

What the catalogue can reach

This is NHI Mgmt Group's view of common catalogue components and what each gives an attacker. Not every deployment has every component; map your own before you need this page.

How the compromise shows up

• Harvester identities used outside their schedule: the catalogue's database user or cloud role active from an unexpected address, at an odd time, or running full table reads where it normally queries system views and samples a few rows.
• Bulk search or export of the catalogue: API reads or downloads of the whole inventory, lineage or "restricted" search results in the catalogue's audit log.
• Classification downgrades: restricted or personal data tags removed or replaced on columns, often in batches, followed by masking or row filters disappearing in the warehouse.
• Owner and steward changes: ownership of sensitive datasets moved to an unfamiliar account, so the attacker becomes the approver for access requests.
• Grants that trace back to the catalogue: new SELECT or read permissions in the data platform created by the catalogue's provisioning identity with no matching approved request.
• New connections or changed connection strings: a harvester pointed at a new host, or a new source added that the attacker controls, a pattern that can capture credentials the catalogue sends.
• A provider notice: an advisory asking customers to rotate connection credentials or tokens.

Triage: the first hour

1. Where did it start? Your tenant (admin, steward, token, SSO), a self-hosted harvester, a stolen connection credential, or the provider's service.
2. Where are connection secrets stored? In the catalogue's own store, in your secrets manager referenced by the catalogue, or on the harvester host. This decides what must be rotated first.
3. Does the catalogue enforce or only describe? If tags, policies or access requests flow back into the warehouse, lake or masking layer, the integrity track is urgent; if it only documents, focus on confidentiality.
4. What is sampled and retained? Confirm whether profiling stores sample values, previews or frequent values, for which sources, and for how long.
5. Which sources are most sensitive? Export the inventory ranked by classification: personal data, payment data, health data, credentials and secrets.
6. Is access ongoing? Recent harvester activity from unknown sources, or tag changes in the last hours, means containment starts now.

Containment by priority

1. Stop write-back first. Disable tag, policy and grant synchronisation from the catalogue into the data platforms, and pause automated access provisioning. This prevents further integrity damage while you investigate.
2. Cut harvester access at each source. Lock the catalogue's database users or rotate their passwords and keys, and remove registered key pairs on warehouse service users. For cloud roles, AWS's revoke sessions action attaches an inline policy named AWSRevokeOlderSessions that denies all actions to sessions whose aws:TokenIssueTime is earlier than the revocation; it does not affect long-term IAM user access keys, which must be deactivated separately. Google Cloud advises disabling a service account key before deleting it once you are sure it is not needed. Microsoft's playbook for compromised applications starts containment by disabling the service principal's sign-in (accountEnabled set to false).
3. Revoke SaaS grants and tokens. Remove the catalogue's OAuth applications and API tokens in each connected SaaS tenant. Under RFC 7009, revoking a refresh token should also invalidate access tokens from the same grant where the server supports it, but access tokens may otherwise stay valid until they expire, so plan for that window.
4. Isolate self-hosted harvesters. Remove network access to sources, keep the host for forensics, and do not reuse it.
5. Lock the catalogue tenant. Disable compromised administrator and steward accounts, revoke API tokens, remove unknown SSO, SCIM and connection changes, and restrict administration to a small break-glass group.
6. Raise monitoring on the sources. Turn on or extend query and object-level logging on the most sensitive stores now, so further misuse of any credential you missed is visible.

Rollback: record every connection, user, role, grant and synchronisation setting you change, with its previous state, so legitimate harvesting can be restored deliberately rather than by re-enabling everything at once.

Checking metadata integrity

This step is what makes a catalogue incident different from most tool compromises. If metadata drives enforcement, the attacker may not need to steal credentials at all: removing a tag can expose a column to every analyst.

Restore from a known good state, then confirm in the data platform that masking, row filters and tag-based grants behave as expected for a test account in each classification level. If you keep no tag history, start now: an export of tag state in version control is the cheapest rollback point available.

Credential rotation and trust reset

Order the work by exposure: sources the logs show were read first, then every other source the catalogue could reach. The Vendor SaaS Breach Response Playbook covers the supplier side when the provider itself was breached.

Where identity fits

Every harvester connection is a non-human identity, usually created by one engineer during onboarding with broader read rights than metadata collection needs, and rarely reviewed again. During rebuild, give each source its own identity, prefer federation and roles over stored passwords and keys, keep secrets in your own vault rather than the catalogue where the product allows, and record an owner and rotation date for each. Separate the identity that reads metadata from any identity that writes tags or grants back. See the Service Account Security Guide.

Scoping the exposure

• Metadata exposure: assume the inventory, lineage and classification of every connected source were read if the console or API was in hostile hands. This is sensitive in itself: it names restricted projects and where regulated data lives.
• Sample exposure: list the sources with profiling samples or previews and treat those values as disclosed.
• Source data exposure: for each high-sensitivity source, pull access logs for the harvester identities across the window and compare volumes, query shapes and source addresses with the normal pattern.
• Exposure through altered access: for every downgraded tag or unmatched grant, check who read the newly exposed data before it was restored.
• Logging gaps: where query logging was off, record that access cannot be ruled out.

The Data Security Incident Scoping Playbook covers this in depth.

Eradication and rebuild

• Hunt in connected platforms: new users, keys, role trust changes and application credentials created during the window (T1098.001 Additional Cloud Credentials).
• Rebuild self-hosted harvesters from clean images, with new host identities and network rules allowing only the sources they need.
• Purge samples: delete stored samples and previews from the window, ask the provider for written confirmation where they hold copies, and shorten retention.
• Clean the tenant: remove unknown administrators, stewards, tokens, connections, policies and saved exports.

Recovery and reconnection

1. Pilot one low-sensitivity source with a new identity and confirm a full harvest cycle shows only the expected queries in the source's logs.
2. Turn sampling down: collect schemas and classifications without storing sample values where possible.
3. Expand in rings by sensitivity, restricted sources last.
4. Re-enable write-back last, with approval for any change that removes a restricted tag or widens a grant.

Evidence to preserve and notification

• Catalogue records: audit log, search and export history, tag and policy change history, connection changes, and the inventory as it stood.
• Source logs: query, object and sign-in logs for every connected source, exported before retention expires.
• Harvester hosts: disk and memory images and network flow records.
• Provider communications: notices, case numbers and statements on samples and retention.

Record each action and its time as you go: NIST SP 800-61 Rev. 3 frames incident response as a CSF 2.0 Community Profile, and CSF 2.0 outcome RS.AN-06 asks that investigation actions are recorded with their integrity and provenance preserved. Personal data is often in scope. Under GDPR Article 33 the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, and a processor must tell the controller without undue delay. Article 34 requires telling individuals where a breach is likely to result in a high risk to them. See the Cyber Incident Reporting Requirements Map for other regimes.

Decision guidance

Detection and measurement

• Time to cut source access: from declaration to every harvester identity disabled or rotated.
• Connection inventory accuracy: percentage of connections with a named owner, identity and documented rotation steps.
• Tag drift: restricted tags removed or downgraded per month, each traced to an approved change.
• Unmatched grants: data platform grants by the catalogue's identity without an approved request (target zero).
• Sample retention: sources storing sample values and the retention period, kept to the minimum.
• Alert tests: harvester identity used off schedule and bulk tag downgrade alerts tested at least yearly.

Framework mapping

Common failure patterns

• Calling it "only metadata". The index, lineage and samples tell an attacker exactly where to go next, and samples may be regulated data.
• Rotating credentials but not checking tags. The access change made through a downgraded tag survives every password reset.
• Waiting for the provider before rotating. In the Sisense breach, a platform holding customers' data source credentials was reportedly breached and CISA urged customers to reset credentials and secrets used with it; customers who know which credentials each vendor holds can rotate quickly.
• One harvester identity for every source. A single shared account turns one leak into estate-wide access and makes scoping impossible.
• Re-enabling write-back with the old rules. Auto-approval and broad provisioning rights recreate the integrity exposure.
• No query logs on the most sensitive stores. Without them you cannot show what was not read.

Practitioner checklist

• Keep a list of every catalogue connection, its identity, secret location, owner and rotation steps.
• Know whether the catalogue writes tags, policies or grants back, and how to switch that off quickly.
• Export tag, owner and policy state to version control on a schedule.
• Freeze write-back first, then cut harvester access at each source.
• Revoke SaaS grants and catalogue API and SCIM tokens alongside database users.
• Diff tags, owners, policies and grants against baseline and restore.
• Scope metadata, sample and source data exposure separately.
• Rotate every connection credential and secrets found in profiled data.
• Reconnect read only, one source at a time, write-back last.
• Start the notification analysis early with legal and the data protection officer.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• GDPR: Article 33 Notification of a personal data breach to the supervisory authority
• AWS: Revoke IAM role temporary security credentials
• Google Cloud: Best practices for managing service account keys
• Microsoft: Compromised and malicious applications investigation
• MITRE ATT&CK: T1213 Data from Information Repositories

Related NHI Mgmt Group resources: Data Governance and Data Catalogue Security Guide · Data Access Governance Guide · Securing the data warehouse and lakehouse itself · If your DSPM platform is compromised · Database Breach Response Playbook