Accountability sits with the teams that own the services, identities and data paths, not just with policy authors or privacy reviewers. When service accounts, integrations or background jobs move personal data, those technical owners must be able to prove the flow was authorised, necessary and observable.
When service identities move personal information, who actually owns the obligation?
The accountable party is not the policy function alone. Accountability rests with the teams that design, run and evidence the service, the integration and the data path, because they control how the data moves and can prove whether the movement was authorised, necessary and observable.
That is a practical ownership question, not just a privacy question. If a background job, service account or integration can move personal information, the operational owner must be able to explain the purpose, the permissions and the logging that makes the flow reviewable.
Why technical ownership matters more than paper approval
A privacy review can approve a pattern, but it cannot operate the pattern day to day. The teams closest to the service are the ones that can see entitlement drift, integration changes and hidden data paths, so they are the only teams able to keep accountability current when the system changes.
This is especially important where service identities are reused across apps, environments or vendors. The accountable owner has to keep the actual trust boundary aligned with the intended one, not just rely on the original design note or data-processing register.
That means accountability follows the control plane as well as the business owner. Where a service account can read, transform or forward personal data, the owner of that account and the owner of the data flow share the burden of proving the access was justified and constrained.
What has to be evidenced for personal data flowing through integrations?
Practitioners should think in terms of proof, not intention. The minimum evidence is usually the identity of the service or job, the source and destination systems, the purpose of the transfer, the permissions used, and the logs or traces that show the flow actually happened as designed.
Good accountability also includes lifecycle questions: who approved the integration, who can change it, who can rotate or revoke the credentials, and who will notice if the job starts moving more data than expected. Without those answers, responsibility is shared in name only.
For identity-heavy architectures, this is where the NHI definition and overview becomes useful because it frames service accounts, tokens, certificates and workload identities as governed access paths, not just implementation details. The related Identity Security Programme Guide is also relevant when ownership needs to be assigned across teams, controls and operating responsibilities.
Risk and Threat Considerations
Personal information moving through service identities creates a common blind spot: the transfer may be technically authorised but still poorly governed, over-broad, or invisible to the teams expected to be accountable. That increases the chance of excess access, unauthorised secondary use, and weak detection when an integration is abused or misconfigured.
Failure mechanism: service accounts, API credentials or background jobs accumulate permissions and data reach beyond the original purpose, then continue to move personal information after business need, ownership or approval has changed.
Impact: teams lose the ability to prove necessity and control, personal data exposure can spread across connected systems, and incident response becomes slower because no one can clearly show which identity moved which data and why.
When the question is about governed movement of personal information, external control frameworks reinforce the same basic expectation that access, logging and accountability must be tied to operating ownership. The EU NIS2 Directive and ISO/IEC 27001:2022 Information Security Management both support the expectation that security ownership, access control and evidence of operation sit with the organisation that runs the system, not with policy text alone.
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 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Service identity data flows need auditable evidence of who moved what. |
| AC-2 — Account Management | Ownership depends on controlling service accounts and their lifecycle. | |
| IA-5 — Authenticator Management | Service identities rely on secrets and tokens that must be managed across the data path. | |
| Recommendation — Log service-to-service data transfers and retain evidence for accountability reviews. Assign and review ownership for every service identity that can move personal data. Rotate and govern service credentials that authorize personal-data movement. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Personal-data integrations depend on controlled access paths and permissions. |
| A.8.15 — Logging | Accountability requires evidence that service identities actually moved data as intended. | |
| Recommendation — Tie each data-moving integration to explicit access rules and named owners. Enable logging for service identities and verify it supports transfer traceability. | ||
Practitioner Guidance
What to verify: for every integration that touches personal information, verify the named service owner, the credential owner, the data owner and the approver are all explicit and current. If any of those roles are missing, accountability is not yet real.
Decision rule: if a service identity can move personal data without an auditable business purpose and an accountable operational owner, treat that as a control gap, even if the data flow was originally approved.
What good looks like: the team running the service can show a current inventory of identities, the systems they touch, the data classes they process and the logs that prove each transfer was authorised and necessary.
Practitioner takeaway: accountability for personal data in service-to-service paths belongs to the operators who can change, observe and evidence the flow, because only they can keep technical reality aligned with the approved purpose.