Ownership should be shared across privacy, legal, security, procurement and the business team running the decision process. Privacy defines the control requirement, procurement secures contractual support, security protects the environment and the business owns the actual decision workflow. Shared responsibility is essential because the obligation follows the outcome, not the tool vendor.
Who should own ADMT compliance when the decision uses third-party tools?
ADMT compliance should be treated as a shared operating responsibility, not a vendor checkbox. The business team that runs the decision process owns the outcome, while privacy, legal, security and procurement each own a different part of the control surface. When a third-party tool is involved, the compliance duty does not move to the vendor; it becomes a governance and accountability problem inside the organisation.
How shared ownership works in practice
The cleanest way to assign ownership is by control function. Privacy defines what the decision process is allowed to do with personal data and automated logic. Legal interprets the external obligation and the contractual language. Security protects the environment, integrations and access paths that make the tool usable. Procurement makes sure the contract, due diligence and supplier obligations support the control. The business team owns the workflow, exceptions and operational acceptance of the automated decision itself.
This split matters because third-party tools often create a false sense of transfer. A tool provider may supply features, attestations or logs, but the organisation still decides whether the automation is appropriate, whether the decision is sufficiently reviewable, and whether the supporting controls actually exist. In practice, ownership should follow the point where the decision is made and where the regulated outcome is produced.
Why vendor involvement does not change accountability
Third-party tooling changes the delivery model, not the responsibility model. If an automated decision affects a person, customer or worker, the organisation using the tool still has to be able to explain the process, validate the inputs, and challenge incorrect outputs. That means the team operating the workflow must stay close to the logic, even when the logic is partially embedded in a platform, API or service.
For that reason, compliance ownership should not sit solely with IT or with the vendor management function. Those teams are important, but they do not own the underlying business decision. The practical test is simple: if a regulator, auditor or complainant asks why the decision happened, the business process owner must be able to answer, and the supporting teams must be able to evidence the controls behind it.
Where the handoffs usually fail
ADMT programmes tend to fail at the seams, not in one team’s isolated work. Privacy may define the requirement but not verify implementation. Procurement may secure good contractual terms but not check whether those terms map to live operational controls. Security may harden the integration but not understand the decision logic. The business may depend on the tool while assuming someone else has already handled compliance. Shared ownership only works if each team has a distinct decision or evidence obligation.
That is especially important with third-party tools because supplier features can change, integrations can drift, and the organisation can lose visibility into how decisions are actually generated. Good ownership therefore includes periodic review of what the tool is doing, who can change it, and whether any new data use, model change or workflow change affects the compliance position.
Risk and Threat Considerations
When ownership is unclear, organisations often discover too late that the vendor contract, the technical configuration and the business decision process do not line up. That creates exposure to unlawful automation, weak challenge rights, poor auditability and unmanaged dependence on a third party.
Failure mechanism: The organisation treats the tool as the owner of compliance, so no single team validates the decision logic, the data use, the supplier obligations and the review process together. Gaps then appear between contract terms, technical controls and actual operations.
Impact: The result can be a decision process that is difficult to defend, hard to audit and expensive to remediate, especially when the organisation must prove that accountability stayed with the user of the tool rather than the tool maker.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022, GDPR and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Third-party decision tooling should be limited to the minimum access needed. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Automated decisions need reviewable evidence and traceability for accountability. | |
| Recommendation — Restrict tool and admin access to the minimum necessary for the automated decision workflow. Review logs and decision evidence regularly so automated outcomes can be explained and challenged. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party tools introduce supplier accountability and control alignment requirements. |
| Recommendation — Define supplier security obligations for the decision tool and verify they are contractually enforceable. | ||
| GDPR | Article 22 — Automated individual decision-making, including profiling | ADMT compliance centers on rights and safeguards for automated decisions affecting individuals. |
| Recommendation — Assess whether Article 22 conditions apply and provide required safeguards where automated decisions are used. | ||
| SOC 2 (AICPA) | CC1.2 — Demonstrates commitment to integrity and ethical values | Shared ownership and accountability are core to trustworthy automated decision governance. |
| Recommendation — Assign accountability for the automated decision process and document who owns each control. | ||
Practitioner Guidance
What to prioritise: Assign one accountable business owner for the decision workflow, then document supporting owners for privacy, legal, security and procurement. If any one of those functions cannot show its specific control responsibility, the ownership model is incomplete.
What to verify: Verify that the contract, DPIA or equivalent review, security review and operational process all point to the same accountable decision owner. If they name different owners, you have a governance gap even if the tool itself is well configured.
Decision rule: If the third-party tool can influence eligibility, approval, scoring or exclusion, treat the compliance question as shared ownership with business accountability, not as a vendor-managed service. If the tool only supports administration without affecting outcome, the ownership can be lighter, but still should not be implicit.
Practitioner takeaway: The safest model is not to “hand ADMT compliance to the vendor”, but to make the business accountable for the outcome and require privacy, legal, security and procurement to each control their part of the risk.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities for SOC 2 compliance?
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
- How should teams respond when AI agents use third-party tools and MCP connections?