Who is accountable for governing sensitive financial data under FCA expectations?

Why This Matters for Security Teams

Under FCA expectations, accountability for sensitive financial data stays with the regulated firm, even when processing is split across SaaS platforms, data pipelines, and delegated service providers. That means the question is not just who has access, but who can prove control over discovery, classification, and use. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives explains why auditability matters when machine access is involved, and the broader NIST Cybersecurity Framework 2.0 reinforces governance, identification, protection, and monitoring as board-level duties.

In practice, firms get into trouble when data ownership is assumed to sit with the platform team, while the compliance team expects the security team to produce evidence after the fact. FCA-style accountability is operational, not theoretical: someone must know where sensitive data lives, who can reach it, and how exceptions are handled. The gap is often not policy language but the absence of continuous visibility into data access and movement. In practice, many security teams encounter that gap only after an incident review, rather than through intentional control design.

How It Works in Practice

Accountability is usually implemented as a chain of responsibilities, not a single person holding every control. The regulated institution owns the risk, while specific control owners manage classification rules, access reviews, retention, logging, and remediation. A defensible model starts with identifying the data estate, mapping business purpose, and recording where sensitive financial data is stored, copied, processed, and exported. That is why visibility platforms such as DSPM are often paired with governance processes: they help create evidence, but they do not replace the obligation to act.

For FCA-aligned programs, the practical workflow is typically:

• discover sensitive datasets across cloud, SaaS, and on-premises locations;
• classify data by sensitivity and business impact;
• map access paths, including non-human identities and third-party integrations;
• review excessive permissions and remove unnecessary exposure;
• document remediation, exceptions, and approvals for audit use.

This is consistent with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, audit logging, and configuration management. It also aligns with NHIMG guidance in Ultimate Guide to NHIs — Key Research and Survey Results, which highlights how often secrets and service accounts remain poorly governed. When firms use NHIs to move or query financial data, the institution still owns the outcome, including the risks created by overprivileged machine access. These controls tend to break down in highly distributed estates where shadow copies, unmanaged APIs, and ad hoc analyst exports make the real data flow invisible.

Common Variations and Edge Cases

Tighter data governance often increases operational overhead, so organisations have to balance control strength against business speed and reporting demands. Best practice is evolving on how much evidence must be automated versus manually reviewed, but there is no universal standard for this yet.

One common edge case is outsourced processing. Even when a vendor hosts the system, the firm still needs to show it understands what data the vendor handles, what access the vendor has, and how that access is limited and reviewed. Another edge case is internal analytics, where teams assume low risk because the data never leaves the firm. In reality, copied extracts, notebooks, and service accounts can create the same accountability problem if they are not monitored. The NHIMG Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because lifecycle control applies to both data access and the identities that touch it. For identity assurance, NIST SP 800-63 Digital Identity Guidelines remains relevant where strong authentication is part of the control evidence. The practical exception is highly ephemeral data flows, where real-time classification may be incomplete and firms must rely on compensating controls, logging, and tighter exception governance.

Related resources from NHI Mgmt Group

• Who is accountable when sensitive data is exposed in email under GDPR, HIPAA, PCI DSS, or SOC 2 expectations?
• Who is accountable when a business misuses UK personal data under DUAA or fails to meet DVS requirements?
• Who is accountable when weak authentication lets unauthorised users reach regulated data or financial services?
• Who is accountable for OAuth governance when third-party apps and AI tools keep access to sensitive data?