Self-hosted secrets management for DORA: what supervisors will ask to see
An EU financial entity preparing for DORA supervision needs a documented encryption policy and full-lifecycle cryptographic key management, both required by Delegated Regulation (EU) 2024/1774. A self-hosted OpenBao cluster, run inside the entity's own cloud accounts, data centers or isolated networks, can hold the key material and produce the access and audit records supervisors ask for. DORA has applied since 17 January 2025, and it sets no certification scheme, so there is no DORA certificate to buy. Competent authorities test compliance using their supervisory powers, and DeployOpen prepares the systems, controls and evidence for that review without issuing audit reports or attestations.
Start with the policy. Article 6 of the Delegated Regulation expects the encryption policy to follow the approved data classification and ICT risk assessment, and to cover data at rest and in transit, internal and external connections, and key management. Article 7 then asks for protection against loss, unauthorised access, disclosure and modification, plus methods to replace keys that are lost, compromised or damaged. Before design starts, confirm with your risk function which ICT assets support critical or important functions, because Article 7(4) requires a certificate register at least for those assets and prompt renewal before expiry. OpenBao's Transit secrets engine can perform encryption as a service so applications do not hold raw keys, but whether that fits a given workload is a design decision to record in the policy.
The evidence file is where most gaps appear. Ask your partner to show, for each key, who generated it, where it is stored, which policies allow its use, when it rotates and how it is destroyed, with the audit log entries that prove each step. Confirm which OpenBao storage backend and HA design you will run, and test restore and unseal procedures in your own environment, since those records underpin the lifecycle claims. Also record any measure where leading practice cannot be met, with a reasoned explanation, as Article 6(3) to (5) require. DeployOpen can document those controls and test them, and your independent auditor or the competent authority decides whether they are sufficient.
Mapping DORA encryption and key requirements to OpenBao configuration
This table maps each DORA encryption and key management requirement in Delegated Regulation (EU) 2024/1774 to what the financial entity must do and how an OpenBao cluster can be configured to support it. Read each row as a question to answer in your own design, then confirm the mapping with your auditor and your competent authority's expectations. The main takeaway is that OpenBao covers much of the key lifecycle and audit evidence, but the policy, risk decisions and certificate register remain the entity's own documented work.
| Requirement | What the function must do | How to configure OpenBao |
|---|---|---|
| Article 6: encryption policy | Document an encryption policy based on the approved data classification and ICT risk assessment, covering data at rest and in transit, internal and external traffic, and key management. | Use Transit secrets engine keys and PKI roles only for data classes named in the policy. Keep policy documents, key inventory and mount layout under version control with owner records. |
| Article 6(2): data in use | Where data in use cannot be encrypted, process it in a separated and protected environment or apply equivalent measures. | OpenBao does not encrypt data in use. Restrict which workloads can call Transit encrypt and decrypt through narrow policies, and isolate the processing environment and its network paths as documented controls. |
| Article 6(3) to (5): exceptions and records | Record each place where leading practice cannot be met, add mitigation and monitoring, and update cryptography as cryptanalysis develops. | Track exceptions outside OpenBao in a register linked to Transit key versions and algorithms. Use audit device logs to show monitoring. Confirm with your assessor which algorithm changes they expect you to evidence. |
| Article 7: key lifecycle from generation to destruction | Cover generation, distribution, storage, use, rotation, backup, retirement and destruction of keys, with defined owners for each stage. | Use Transit key creation, rotate and min_decryption_version settings, plus deletion_allowed set to false until retirement is approved. Document destruction steps and the storage backup retention that holds old key material. |
| Article 7: protection against loss, unauthorised access and disclosure | Protect keys from loss, unauthorised access, disclosure and modification through access control, custody of unseal material and tamper-evident records. | Use separate policies per team, short-lived tokens from trusted auth methods such as JWT/OIDC or AppRole, Shamir or auto-unseal custody agreed in writing, and a tested backup of the storage backend. Confirm your unseal design with the vendor and your own environment. |
| Key replacement for lost, compromised or damaged keys | Have tested methods to replace keys that are lost, compromised or damaged, and show when they were used. | Rotate Transit keys and re-wrap ciphertext, revoke leases and tokens in bulk, and rehearse restoration from backup. Record each replacement event in the audit log and the incident record. |
| Article 7(4) and (5): certificate register | Keep a register of certificates and certificate-storing devices, at least for ICT assets supporting critical or important functions. | Use PKI secrets engine roles to issue certificates with consistent naming and metadata. Export issuance and revocation data to your asset register. Confirm that the register covers devices and certificates outside OpenBao. |
| Article 7(5): prompt certificate renewal | Renew certificates before they expire, with monitoring that flags upcoming expiry. | Set PKI role TTLs to match your renewal process, automate issuance through an approved client, and alert on expiring leases or certificates from the audit and monitoring stack. Test renewal in a non-production cluster first. |
How an OpenBao cluster covers key lifecycle, access and audit
The Transit secrets engine is the component most directly tied to the key lifecycle requirements in Article 7 of Delegated Regulation (EU) 2024/1774. It performs encryption as a service, so applications send data to OpenBao to be encrypted or decrypted while the named key material stays inside the cluster. Keys are versioned, which lets an entity introduce a new key version for new data while older ciphertext remains readable under the earlier version. An entity should map each Transit key to a data classification and a named owner, then document how generation, rotation and retirement are handled for that key.
- Key generation: Keys are created inside OpenBao with a defined type and name, so the entity can register each key against the ICT asset that depends on it.
- Versioned rotation: New key versions support gradual re-encryption of stored data, which helps with the requirement to replace keys without losing access to records.
- Key protection: Key material is held under the cluster's seal and encryption configuration, so access depends on policies and unseal custody, not on application code.
- Deletion and retention: Confirm in the official Transit documentation how key deletion, minimum decryption versions and archive behaviour work before you define a destruction procedure.
Before relying on Transit for regulated data, ask your implementation partner to show a tested rotation and a tested re-encryption run, and confirm the deletion behaviour in the official OpenBao Transit documentation for the version you deploy.
Stored credentials, such as service passwords and API tokens, are the second area of key management that supervisors ask about. OpenBao's key/value engine stores secrets encrypted before they reach the storage backend, and dynamic secrets issue short-lived database or system credentials that expire automatically. Leasing and revocation mean an entity can cut off access for one credential, for one application or in bulk when an incident requires it. The control question is whether each credential has an owner, a rotation trigger and a documented way to replace it if it is lost or compromised.
- Encrypted storage: Secrets are encrypted before they are written to the storage backend, so the storage layer does not hold readable values.
- Dynamic credentials: Database and system accounts can be issued per consumer with a lease, reducing the number of long-lived shared passwords.
- Lease revocation: Individual leases and bulk revocation give the security team a tested method to respond to a suspected compromise.
- Versioned key/value data: Keep the versioning and metadata settings consistent with your retention and destruction rules.
Check that your rotation runbook covers every static secret that cannot be made dynamic, and ask for the list of which credentials rotate automatically and which need a manual change window.
Article 7(4) and (5) of Delegated Regulation (EU) 2024/1774 require a register of certificates and certificate-storing devices, at least for ICT assets that support critical or important functions, and prompt renewal before expiry. OpenBao's PKI secrets engine can issue internal certificates from a private certificate authority that the entity controls. This allows certificate issuance, renewal and revocation to be logged in the same audit trail as the key operations. Whether a private CA suits a given entity depends on its certificate chain, trust stores and the systems that consume the certificates, so the design should be settled before any issuance.
- Private CA hierarchy: Decide whether to run a root and intermediate chain inside OpenBao or to keep the root offline and sign intermediates, based on your risk assessment.
- Issuance roles: Define roles that limit which names, key types and lifetimes each team may request.
- Renewal automation: Short lifetimes raise the need for automated renewal, so map which ICT assets can renew without manual steps.
- Certificate register: Export issuance and revocation records to the register that Article 7 requires, and keep it current for critical assets.
Ask the partner how the certificate register is populated, which systems are not covered by automated renewal, and how revocation is tested before go-live.
Access control is where supervisors look for evidence that only authorised people and workloads can use keys. OpenBao documents a range of auth methods, including AppRole, JWT/OIDC, Kerberos, Kubernetes, LDAP, RADIUS, TLS certificates, tokens and username and password, and it supports login MFA. The official guidance recommends Userpass for developer machines and AppRole for servers. Policies bind each identity to the paths and operations it may use, so the access model can be reviewed against the entity's identity governance records.
- Server identities: AppRole suits servers and services, with the secret ID delivered by a controlled process rather than stored in code.
- Human access: Use OIDC or LDAP federation with the workforce directory, and enable login MFA for administrative and key-operator roles.
- Workload identity: Kubernetes and JWT/OIDC login let pipelines and pods authenticate without static tokens.
- Least privilege policies: Scope each policy to specific key names and operations, and keep administrative policies separate from usage policies.
Ask the partner to produce the policy-to-role map, confirm which auth methods are enabled in production, and show how MFA enforcement is verified for every operator path.
Supervisors expect evidence of who used which key and when, and they expect the cluster to remain available for the systems that depend on it. OpenBao's audit devices record requests and responses for the cluster, and the storage choice shapes both availability and operations. OpenBao documents integrated storage (Raft) and PostgreSQL as the officially supported high availability backends. The docs describe PostgreSQL as an easier backend to operate safely than Raft, and since OpenBao 2.5.0, Raft standbys can serve read-only operations, with v2.7.0 extending this to PostgreSQL. OpenBao is licensed under MPL-2.0 and is a Linux Foundation OpenSSF Sandbox project, which matters for how the entity documents its open-source dependencies.
- Audit devices: Enable at least one audit device and forward its logs to a store the entity controls, so records survive a node failure.
- Raft integrated storage: Keeps the cluster self-contained, but the team must run the replication and snapshot procedures itself.
- PostgreSQL backend: Moves replication and backup to a database platform the entity may already operate, which can simplify evidence collection.
- Read scaling: Standbys that serve reads can be a design choice, but confirm which operations route to them for your version.
- Licensing record: Note the MPL-2.0 license and OpenSSF stewardship in the third-party register.
Before approving the design, confirm the backend choice, the audit log retention and the restore test in writing with your partner, and check the official OpenBao high availability and storage documentation for the version you deploy.
Which open-source platforms fit DORA key management
DORA's encryption and key management rules are met by a set of components, not one product. The cards below pair a key manager with the identity, log and lifecycle tools that supply the evidence supervisors ask for, and flag the licensing terms to check before committing.
OpenBao as the core key manager
OpenBao holds the key lifecycle, encryption as a service and access policies in the entity's own infrastructure. Its MPL-2.0 license covers the repository, so the core can be audited and run without a per-seat or per-node fee. Check which storage backend and unseal design you will run, because high availability depends on it, and confirm that any enterprise add-ons you need are offered under separate terms.
Infisical as an alternative
Infisical covers secrets, certificates and access under an MIT license for most of its code. Content in the ee directories is under a separate enterprise license, so confirm which features your team needs fall outside that boundary before standardizing on it. It fits teams that want a developer-facing interface and certificate handling in one tool, but its key lifecycle and audit controls need the same review against your DORA evidence list as OpenBao's.
Wazuh or Security Onion for audit logs
Key access events from OpenBao must reach a store that the entity can retain and examine. Wazuh (GPL-2.0 core) and Security Onion (Elastic License 2.0) can both act as log destinations and monitoring consoles. Check the license terms of Security Onion before embedding it in a commercial service, and confirm how each platform handles retention, tamper protection and integrity of the forwarded logs.
Keycloak or authentik for workforce login
Administrators who unseal, configure or read secrets need strong, individually attributable sign-in. Keycloak (Apache-2.0) and authentik (MIT, with an enterprise directory under a separate license) can federate OpenBao logins through OIDC, so each operator uses a named identity and MFA rather than shared tokens. Confirm which MFA methods your identity provider enforces and how break-glass accounts are recorded.
midPoint for leaver evidence
Access to key material should end when a person changes role or leaves. midPoint (EUPL 1.2 or later) can drive joiner, mover and leaver provisioning and feed the group membership that OpenBao policies rely on. Verify that removals propagate to OpenBao's auth methods within the time your procedures require, and keep the provisioning and recertification records as evidence that access policies were reviewed.
Designing key ownership, unseal and recovery for supervisors
Under the Article 7 key protection requirement of Delegated Regulation (EU) 2024/1774, a supervisor will probe three things before anything else in an OpenBao deployment: who holds the unseal and recovery material, how key ceremonies are run and evidenced, and who can change administrative roles. The entity should be able to name each holder, the custody location and the approval path for every one of these. Those answers belong in the key management policy the entity already maintains under Article 6, so the OpenBao design should reference that policy rather than sit in a separate document.
The design choices to document include the number of unseal key shares and the threshold needed to reconstruct the root key, whether recovery keys are held separately from unseal keys, how shares are split among named custodians, and where each share is stored offline. Document the process for generating the root material, the witnesses present, the recording of each ceremony, and the procedure for rotating shares after a custodian leaves. Also record which identities may hold policies that grant administrative capabilities, how those identities authenticate, and whether any single person can both read a secret and alter its audit configuration. Confirm the exact initialization, unseal and recovery parameters, and the behaviour of the recovery procedure, against the OpenBao documentation for the version you deploy, since the current stable line is v2.7.1 (published October 1, 2026). Test a full recovery in a non-production environment and keep the result as evidence.
Evidence supervisors and auditors ask for and where it comes from
This table maps each artifact a supervisor or independent auditor is likely to request for encryption and key management under Delegated Regulation (EU) 2024/1774 to the question it answers and the component that produces it. Read it as a collection plan: most items come from OpenBao audit devices, policy files and change records, while the policy and risk decisions remain the entity's own documents. DeployOpen prepares these systems and evidence for assessment but does not issue audit reports, attestations or certifications.
| Evidence item | What it proves | Which component produces it |
|---|---|---|
| Encryption policy document | Encryption and key management rules exist, cover data at rest, in transit and in use, and match the ICT risk assessment (Article 6) | Entity governance records, drafted with the risk function and approved by management; OpenBao configuration referenced as implementation |
| Data classification link | Key scope and protection levels trace back to the approved data classification | Entity data classification register, mapped to OpenBao mounts, namespaces and transit key names |
| Key inventory and lifecycle records | Each key has an owner, purpose, creation date and state from generation through destruction (Article 7) | OpenBao transit and KV metadata, key version history, exported inventory reviewed on a set cadence |
| Rotation and replacement procedure records | Lost, compromised or damaged keys can be replaced, and rotation is performed as documented | Runbooks plus OpenBao rotate and key version audit entries, with change tickets linked to each event |
| Access policy and role definitions | Only named roles can generate, use, export or administer keys, following least privilege | OpenBao ACL policy files in version control, auth role definitions (for example AppRole or JWT/OIDC), and identity provider group mappings |
| Audit log extracts from OpenBao and SIEM | Who used which key, when, from where, and whether any operation failed or was denied | OpenBao audit devices shipped to the entity SIEM, with retention settings and integrity controls kept in the entity's own infrastructure |
| Certificate register and renewal records | Certificates and certificate-storing devices are listed for critical or important functions and renewed before expiry (Article 7(4) and (5)) | OpenBao PKI engine inventory or a separate certificate register, plus renewal logs and expiry alerts |
| Records of compensating measures under Article 6(3) to (5) | Where a leading practice cannot be met, a reasoned explanation, mitigation, monitoring and crypto updates are documented | Risk register entries and approval records owned by the entity, with monitoring evidence from OpenBao and SIEM alerts |
What OpenBao alone does not satisfy under DORA
A self-hosted OpenBao cluster covers much of the technical key lifecycle work, but DORA's ICT risk management rules also expect written policy, data classification, hardware custody choices, provider oversight, incident handling and trained people. The cards below cover the items that sit outside the software and that supervisors will still ask about.
Written encryption policy and governance
Article 6 of Delegated Regulation (EU) 2024/1774 expects a documented encryption policy that is part of the ICT risk management framework. Someone at management body level must own it, approve it and review it. OpenBao enforces what the policy says but does not write or approve the policy. Check that the policy names key owners, covers data at rest, in transit and in use where applicable, and that its approval and review dates are recorded.
Data classification inputs
The encryption policy must rest on the approved data classification and the ICT risk assessment. OpenBao can protect any secret or key it holds, but it cannot tell you which datasets are critical, which contain personal data or which systems support critical or important functions. Before choosing key scopes, transit keys or namespaces, confirm that the classification exists, is current and maps each system to the keys that protect it.
HSM and hardware custody decisions
Where the entity decides that keys must sit in hardware, OpenBao's software storage does not provide that on its own. The decision belongs in the risk assessment and must be recorded with its reasoning, along with any compensating measures if hardware is not used. Confirm with the partner how root keys, unseal material and recovery keys will be held, who holds each part, and how that custody is evidenced.
Third-party ICT provider oversight
If a managed hosting provider, a cloud platform or an external support firm operates any part of the cluster or its backups, DORA's third-party risk chapter applies on top of the key rules. The entity must hold contractual terms on access, audit rights, location of data and exit. Ask every provider which personnel can reach unseal material, backup copies or administrative sessions, and document that answer in the register of information.
Incident and reporting procedures
A compromised key or an unauthorized read of a secret can trigger a major ICT-related incident assessment under Chapter III. OpenBao's audit logs help establish what happened, but the entity still needs a runbook that covers revoking tokens, rotating affected keys, re-encrypting data and deciding who notifies the competent authority. Test this runbook against a simulated key compromise and keep the results.
Training and testing under Chapter IV
Operators who unseal the cluster, approve key changes and respond to incidents need documented training, and the key management controls belong in the digital operational resilience testing program. A tool that is never tested under failure conditions gives supervisors little to examine. Ask the partner to include restore drills, unseal ceremonies and key replacement exercises in the test plan, and to record who attended and what failed.
How much effort and cost does DORA key management take to implement?
What drives the cost of self-hosted DORA key management?
The cost depends mainly on the size of the key estate, how many applications need integration, how highly available the cluster must be, and how much operations time the entity commits to. Infrastructure for OpenBao is one-time setup plus recurring hosting, storage and backup costs, while integration work per application and ongoing operations are the largest recurring items. OpenBao itself is licensed under MPL-2.0, so there is no license fee to model, but the entity still pays for the people and infrastructure that run it. Ask any partner to split a quote into one-time design, per-application integration, HA and backup infrastructure, and recurring operations so the totals can be compared fairly.
How long does an OpenBao key management rollout usually take?
Timeline depends on how many systems hold keys or secrets, how mature the current key inventory is, and whether the entity needs HSM-backed custody or a migration from an existing secrets store. Work usually starts with classification and a key inventory, then design of the cluster, unseal and recovery approach, auth methods and policies, then application onboarding in waves. No duration is fixed here, so ask for a phased plan in the written scope, with each phase tied to named deliverables and acceptance criteria. Most engagements are fixed-scope, so the agreed scope and timeline should be documented before work begins.
What must the financial entity supply before a partner can scope the work?
The partner needs the approved data classification, the ICT risk assessment that Article 6 of Delegated Regulation (EU) 2024/1774 refers to, and a list of ICT assets that support critical or important functions. It also needs named owners for each key, certificate and application, plus the current encryption policy if one exists. Without these, scope cannot be estimated reliably, because the entity cannot show which keys must be tracked or which systems need the strictest controls. Gathering owners early is often the slowest step, so confirm who in the organization can make decisions on key ownership and access.
Can an internal team run DORA key management without outside help?
An internal team can run OpenBao if it has engineers who understand PKI, identity, cluster operations and backup and recovery, and if it has time to maintain the platform after go-live. The harder part for many entities is the governance work: a documented key lifecycle, rotation rules, access reviews and evidence that a supervisor can follow. A partner can help with design, implementation, hardening, documentation and testing, while the entity keeps ownership of policy decisions. Assess internal skills honestly against the scope before deciding, and ask a partner to state which tasks it would leave with the client's team.
Is OpenBao the right choice compared with Infisical for DORA key management?
OpenBao is usually the stronger fit when the requirement centers on infrastructure-level key management, dynamic secrets, encryption as a service and audit logs for systems that run in the entity's own data center or cloud account. Infisical, which is licensed under MIT except for content in ee directories, is designed around secrets, certificates and access with a developer-friendly workflow, so it can suit teams that prioritize that experience. Confirm the features each option provides for your specific key types, HA design, audit export and HSM needs, and check the license terms for any enterprise-licensed components before choosing. A short proof of concept against your own key types is a practical way to compare them.
Does DeployOpen issue DORA compliance certificates for our key management?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. DORA itself sets no certification scheme, and competent authorities supervise compliance using their powers under Article 50. The entity should plan for its own internal review and any independent assessment it chooses, while DeployOpen supplies the configuration, runbooks and records that support that work.
What ongoing effort follows the initial rollout?
Once keys and secrets are onboarded, the recurring work includes monitoring the cluster, applying upgrades, rotating keys and certificates on schedule, reviewing access policies, testing backups and restores, and keeping the register of certificates current. Each of these recurs for the life of the platform and should be assigned to a named owner. Ask any partner whether ongoing support is offered as a retainer, what it covers, and how upgrades and testing are scheduled, since these tasks determine the long-term operations cost.
How the rollout moves from key inventory to supervisor-ready evidence
The sequence starts from a complete picture of keys and certificates, aligns the rules to the entity's own policy, and ends with evidence a supervisor can test. Each step has a defined output, and the timing of each step is agreed in the written scope.
Build the key and certificate inventory
DeployOpen works with the entity's security, architecture and application owners to list every encryption key, certificate, certificate-storing device and secret store in scope, including keys held by ICT third-party providers. The inventory records owner, purpose, algorithm, location, expiry and the critical or important function each asset supports. It is done when the register covers every asset tied to a critical or important function and each gap has a named owner.
Align the encryption policy with classification
The team maps the inventory to the approved data classification and the ICT risk assessment, then drafts or updates the encryption and cryptographic key management policy that Article 6 of Delegated Regulation (EU) 2024/1774 requires. Where a leading practice cannot be met, the policy sets out the mitigating and monitoring measure and the reasoned explanation to be recorded. It is done when the policy is approved by the accountable function and every key class has a lifecycle owner.
Build the OpenBao cluster with HA and audit forwarding
DeployOpen installs the OpenBao cluster inside the entity's own infrastructure, choosing the storage backend and high availability design the entity's operations team can run safely. Seal and recovery design, TLS, auth methods and audit devices are configured, and audit logs are forwarded to the entity's log platform. It is done when a failover test passes, audit events arrive in the central store and the unseal process is documented and witnessed.
Migrate applications and keys under access policies
Applications, pipelines and services are moved onto the cluster in waves, with each secret or key class given a policy that grants only the access its owner approved. Key generation, rotation schedules and replacement procedures for lost or compromised keys are set up for each class, and legacy keys are retired on a documented schedule. It is done when every in-scope application reads keys from the cluster, each policy has a named owner and rotation runs are visible in the logs.
Assemble the evidence pack and test recovery
DeployOpen compiles the evidence a supervisor is likely to request: the policy, the asset register, configuration baselines, policy and access reviews, rotation and renewal records, audit log samples and the register of mitigating measures. The entity then runs a documented recovery test from backups and unseal material, and the results are recorded. It is done when the pack is reviewed by the entity's compliance lead and the recovery test result is signed off. DeployOpen prepares this evidence; independent assessors and the competent authority judge it.
How DeployOpen scopes, delivers and supports DORA key management
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including OpenBao for key lifecycle and access control. For DORA key management, the work starts with a written scope that ties each key class to the entity's ICT risk assessment and data classification, then carries that scope through build, testing and handover.
How we scope
- Map which keys, certificates and secrets support critical or important functions, and which sit outside that scope.
- Agree in writing the cryptographic key lifecycle stages, rotation rules and access policies the OpenBao cluster will enforce.
- Confirm storage backend, high availability design and placement inside your own cloud accounts or data centers before work starts.
How we build
- Deploy and configure OpenBao with auth methods, policies and audit devices set to the approved scope.
- Test key replacement for lost, compromised or damaged keys, plus certificate renewal ahead of expiry, before go-live.
- Document each configuration decision and the reasoning behind any mitigation where a leading practice cannot be met.
How we hand over
- Deliver runbooks for unseal, backup, recovery and key rotation, with the owners named for each procedure.
- Provide a register of certificates and certificate-storing devices, plus exported audit log configuration for your SIEM.
- Prepare evidence packs that your internal teams and independent assessors can review. DeployOpen does not issue audit reports or attestations.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope.
- Re-run key lifecycle and recovery tests after OpenBao upgrades or changes to the supervised ICT environment.
- Keep documentation current as the entity's risk assessment, data classification and third-party arrangements change.
