Access Control Compliance for FCA-Regulated Fintechs (2026)

If you're running an FCA-regulated fintech and somebody asks "who has access to what right now?", you need to answer with evidence. Not in a week. Not after pulling a favour from IT. Right now.

That's what access control compliance comes down to for regulated fintechs. And it's harder than it sounds.

I've worked with fintechs at different stages of growth, and the pattern is consistent. Access was set up when speed mattered more than governance. The team grew, roles changed, and nobody tidied up who could reach what.

Then the FCA, a prospective enterprise customer, or a DORA assessment turns up. Suddenly proving access control becomes urgent. This guide covers the full picture: why the FCA cares, what good IAM looks like on Microsoft, how to build audit trails that survive scrutiny, and the practical steps to get there.

Key Takeaways: Access Control Compliance for FCA-Regulated Fintechs

• FCA-regulated fintechs must prove who has access to what systems and data, on demand, with auditable evidence.
• Identity and access management on Microsoft Entra ID provides the foundation for least-privilege access and provable controls.
• Audit trails need to capture every access grant, change, and revocation, tied to a named individual and a business justification.
• Yobah helps fintechs build access models on Entra that turn assumed access into provable, reviewable governance.
• Joiner, mover, leaver processes are the single biggest source of access drift and the first thing assessors check.

Why the FCA Cares About Access Control in Fintechs

The FCA doesn't publish a checklist of access control settings you need to configure. What it publishes, through its Financial Crime Guide and the SYSC rules, is an expectation that firms maintain systems and controls appropriate to their business.

The FCA's supervisory approach focuses on whether you can demonstrate that access to sensitive systems is governed, reviewed, and proportionate. FCG Chapter 5 on data security explicitly asks firms how responsibility for data security is apportioned and whether access controls match the risk.

If your answer is "we think it's fine", that isn't going to hold up. The 2025 Monzo enforcement action showed exactly what happens when access controls don't keep pace with growth. The FCA found that onboarding and access processes failed to scale, and the fine was north of £21 million.

For a scaling fintech, the lesson is clear. Access governance isn't something you retrofit when you get big. It's something you build into the fabric from day one, or as close to day one as you can manage.

What Does Access Control Compliance Actually Require?

Access control compliance for FCA-regulated firms rests on a few core principles. You need to know who has access to what, prove that access was granted for a valid business reason, and show that access is removed when it's no longer needed.

That sounds straightforward (note, not straightforward in practice). Most fintechs don't start with a clean identity model. Access accumulates, people change roles without losing old permissions, and shared accounts fill gaps nobody planned for. We'd call it access sprawl, and it's the norm.

At a practical level, the requirements map to a few specific capabilities:

• Least-privilege access: Users should only have the permissions they need for their current role.
• Role-based access control: Access should be tied to defined roles, not granted ad hoc to individuals.
• Access reviews: Periodic, documented reviews of who holds what access, with revocation of anything no longer justified.
• Audit logging: Every access grant, modification, and removal logged with a timestamp, the approver's identity, and the reason.
• Privileged access management: Admin and elevated roles require additional controls, including time-limited activation and MFA.

How DORA Raises the Bar for Access Governance

If you're an FCA-regulated fintech that also operates in the EU or serves EU-based customers, DORA adds another layer of obligation. The Digital Operational Resilience Act ensures that financial entities can withstand, respond to, and recover from ICT-related disruptions.

DORA requires firms to implement identity and access management policies that cover identification, authentication, and authorisation. It expects firms to manage privileged access tightly, log access events, and test controls through threat-led penetration testing.

The regulation also extends accountability to ICT third-party providers. Your access controls need to cover not just your own team, but anyone who touches your systems.

For most fintechs we work with, DORA doesn't introduce fundamentally new concepts. What it does is formalise expectations that many firms were already working towards. It removes the ambiguity about whether access governance is optional. It isn't.

Building an IAM Model on Microsoft Entra ID

Most fintechs we see are running their identity on some version of the Microsoft stack. That usually means Entra ID for identity, with Microsoft 365 handling email, collaboration, and increasingly, regulated workflows.

Entra ID provides a solid foundation for building the kind of access model that regulators and enterprise customers expect. Having the tooling and having it properly configured are two very different things, though.

A well-designed Entra ID model starts with understanding your roles, your applications, and your data classification. You define roles reflecting actual job functions, map them to the applications each function needs, and build conditional access policies that enforce the rules automatically.

Yobah designs identity frameworks on Entra that give fintechs clean, provable access models from the ground up. In our experience, the biggest gap is usually between what the business thinks its access model looks like and what it actually looks like.

Conditional Access: Policies That Enforce Context-Aware Controls

Conditional access moves you from static rules to dynamic, context-aware controls. A conditional access policy evaluates the user, the device, the location, and the risk level before granting access.

If any of those signals fall outside your policies, the request is blocked or stepped up to additional authentication. For FCA-regulated fintechs, this is particularly useful because it lets you enforce different rules for different risk levels.

A user accessing email from a managed device gets a different experience from someone accessing a sensitive financial system from an unmanaged device overseas. That differentiation is what regulators want to see.

Our advice is to start with a baseline covering MFA enforcement, device compliance, and location-based restrictions. Layer on more granular rules as you understand your access patterns. Trying to design the perfect policy set from day one usually stalls the project.

Privileged Identity Management: Eliminating Standing Access

Standing privileged access is one of the biggest risks in any environment, and it's the control fintechs most commonly get wrong. If your Global Administrator accounts are permanently active, anyone who compromises those credentials has the keys to everything.

Privileged Identity Management (PIM) in Entra ID P2 solves this by making admin access just-in-time. A user requests activation when needed, provides a justification, authenticates with MFA, and receives the role for a defined window. Every activation is logged. Every expiration is automatic.

This is exactly the kind of control that generates the audit evidence regulators and auditors expect. We'd recommend PIM for any fintech running Entra ID P2. The investment in the P2 licence pays for itself in governance capability alone.

Audit Trails That Survive Regulatory Scrutiny

An access control model is only as good as the evidence it generates. If you can't show an auditor a clear record of who had access to what, when it was granted, who approved it, and when it was revoked, your controls aren't provable.

Controls that aren't provable might as well not exist, from a compliance perspective. Audit trails for access control compliance need to capture several things consistently:

• Who: The identity of the user whose access changed, linked to a unique identifier.
• What: The specific role, group, or permission that was granted, changed, or removed.
• When: A timestamp for every event, stored in a tamper-resistant format.
• Why: The business justification for the access change, captured at the point of request.
• Who approved: The identity of the person who authorised the change.

On the Microsoft stack, these logs come from multiple sources. Entra ID sign-in and audit logs capture authentication and directory changes. PIM logs capture privileged role activations. Microsoft Purview audit logs capture data access events within Microsoft 365.

Pulling these together into a single, searchable view is where most fintechs struggle. A properly configured Microsoft 365 estate makes a real difference here.

Retention and Tamper Protection for Access Logs

The ICO's records management guidance is clear that access logs need to be retained for the appropriate period, protected from tampering, and accessible for audit.

For fintechs operating under the Money Laundering Regulations, CDD and transaction records must be kept for five years from the end of the relationship. That sets a practical floor for how long your access records should be retained.

We'd recommend centralising your access logs into a SIEM or dedicated log management platform with write-once storage. The native retention in Entra ID and Microsoft 365 is a starting point, but for a regulated firm it's rarely sufficient on its own.

Joiner, Mover, Leaver: Where Access Governance Breaks Down

If there's one process that determines whether your access governance actually works, it's joiner, mover, leaver (JML). This lifecycle process controls what happens to someone's access when they join, change role, or leave.

Get JML right and your access model stays clean. Get it wrong, and access drift is inevitable.

The uncomfortable truth is that most fintechs we encounter have a joiner process of varying quality, a leaver process that usually works for permanent staff, and almost nothing for movers. When someone changes role, new access gets added but old access rarely gets removed.

Over time, you end up with people who've accumulated permissions from every role they've ever held. That's a compliance problem and a security risk. Yobah builds JML automation on Entra so that access follows the person automatically.

How to Run Access Reviews That Regulators Accept

Periodic access reviews are a regulatory expectation, not an optional extra. The ICO's audit framework explicitly lists regular review of user access rights as a core control measure.

An access review that regulators accept needs to be documented, systematic, and tied to business ownership. The person approving continued access should be the line manager or data owner who understands why the access is needed, not the IT team rubber-stamping a spreadsheet.

In Entra ID, access reviews can run automatically on a schedule. Reviewers receive a list of users and their current access, confirm or revoke each one, and the results are logged. Any access not confirmed within the review window can be automatically removed.

This is the kind of structured, evidenced approach that turns access governance from a manual burden into an auditable process.

Zero Trust: Moving Beyond the Network Perimeter

The traditional model of access control relied on the network perimeter. If you were inside the firewall, you were trusted. That model stopped making sense the moment your team started working remotely and your applications moved to the cloud.

Zero trust is the model that replaced it. No access is assumed based on network location, device, or prior authentication. Every request is verified independently, every time.

For FCA-regulated fintechs, zero trust isn't just a security posture. It's the access model that aligns with what regulators expect: provable, granular, and context-aware.

On the Microsoft stack, zero trust is implemented through Entra ID for identity, conditional access for policy enforcement, Intune for device compliance, and Defender for threat detection. Yobah helps fintechs design and deploy zero trust access models tied to their regulatory obligations.

UK GDPR and Data Protection: The Access Control Angle

Access control compliance isn't just about financial regulation. Under the UK GDPR, you have a specific obligation to ensure personal data can only be accessed by those authorised to do so.

Article 5(1)(f) requires that personal data is processed in a manner ensuring appropriate security, including protection against unauthorised access. Article 32 requires technical and organisational measures appropriate to the risk.

The ICO's guide to data security spells this out in practical terms: an access control policy limiting access to authorised staff, a formal provisioning process, regular reviews, restricted privileged access, and logs showing who accessed what and when.

For fintechs processing customer financial data alongside personal data, the intersection of FCA and ICO expectations creates a high bar. A well-designed IAM model on Entra addresses both sets of requirements simultaneously. You need one identity model, properly built and properly evidenced.

A Step-by-Step Approach to Proving Access Control Compliance

Getting from where you are today to a provable access control posture doesn't happen overnight. In our experience, the most successful projects follow a structured sequence that prioritises risk reduction and quick evidence wins first.

Step 1: Map Your Current Access Landscape

Before you can fix anything, you need to know what you're dealing with. Run a full audit of every identity in your Entra ID tenant, every group membership, every application assignment, and every privileged role.

Document what you find. In our experience, this step alone surfaces problems the business didn't know existed: shared accounts, orphaned identities, standing admin rights nobody remembers granting.

Step 2: Define Your Target Access Model

Based on your roles, applications, and regulatory obligations, define what access should look like. Map roles to permissions. Identify which roles need privileged access and which don't. Set the rules for conditional access. This is the design phase.

Step 3: Implement Least-Privilege and PIM

Start removing standing access that doesn't need to be permanent. Enable PIM for privileged roles. Configure conditional access policies. Enforce MFA where it should be enforced. Each change reduces risk and generates audit evidence from the moment it goes live.

Step 4: Automate Your JML Process

Connect your HR system to Entra so that access changes follow role changes automatically. Define the rules for joiners, movers, and leavers. Test the automation thoroughly before go-live, and make sure the leaver process is watertight.

Step 5: Establish Ongoing Access Reviews

Configure periodic access reviews in Entra. Assign reviewers with the business context to make informed decisions. Set auto-revocation for unconfirmed access. Run the first review cycle and document the results.

Step 6: Centralise and Protect Your Audit Logs

Pull your Entra audit logs, PIM activation logs, and Microsoft 365 activity logs into a central platform. Set retention policies that meet your obligations. When the FCA or an enterprise buyer asks for evidence, you should produce it within hours, not weeks.

Common Mistakes Fintechs Make with Access Control

Having worked with a range of fintechs at different stages, there are a few patterns that come up repeatedly. Being honest about these is more useful than pretending they don't happen.

Treating access control as an IT problem rather than a governance problem. The IT team implements the controls, but the business owns the decisions about who should have access to what. If reviews are signed off by someone without business context, they're not serving their purpose.

Ignoring movers. The mover process is almost always the weakest link. People accumulate access throughout their career, and without active revocation, your access model degrades over time.

Relying on shared accounts. Shared accounts make it impossible to attribute actions to individuals. From a compliance perspective, they undermine everything. Every account touching regulated data should be linked to a single, identifiable person.

Assuming "we use MFA" is enough. MFA proves that the person logging in is likely who they say they are. It doesn't prove they should have the access they're using. MFA and access governance are complementary, not interchangeable.

How Yobah Approaches Access Control for Regulated Fintechs

Yobah works specifically with FCA-regulated fintechs on identity and access management, cyber security strategy, and the Microsoft 365 estate underneath both. Our approach starts with understanding your obligations and mapping your current posture against them.

We design and run access on Microsoft Entra, cut standing privilege with PIM, automate JML, and build the audit trails that prove your controls to the FCA, enterprise buyers, and anyone else who asks. Every control we put in comes with the documentation that proves it, before anybody asks for it.

If you recognise any of the problems in this guide, or you're preparing for an FCA assessment, a DORA review, or an enterprise security questionnaire, we'd recommend booking a security review. It's a 30-minute conversation with somebody senior, not a sales pitch.

FAQs About Access Control Compliance for FCA-Regulated Fintechs

What is access control compliance for FCA-regulated fintechs?

Access control compliance means proving that your organisation governs who can access which systems and data, with documented evidence of every grant, review, and revocation. The FCA expects regulated firms to maintain systems and controls proportionate to their risk.

Does the FCA specify which access control tools fintechs should use?

No. The FCA requires firms to maintain appropriate systems and controls, but does not prescribe specific tools. The controls must be proportionate and evidenced. Many fintechs choose Microsoft Entra ID because it integrates with the Microsoft 365 estate they already run.

How does Yobah help fintechs with access control compliance?

Yobah designs and implements identity and access management models on Microsoft Entra for FCA-regulated fintechs. That includes access review and cleanup, PIM for privileged access, conditional access policies, JML automation, and audit trail configuration that proves your controls on demand.

What are audit trails and why do they matter for FCA compliance?

Audit trails are timestamped records of every access-related event: who was granted access, what they were granted, who approved it, and when it was removed. The FCA and ICO expect regulated firms to produce this evidence on request. Without it, your controls are assumed to be insufficient.

How often should FCA-regulated fintechs run access reviews?

There is no single mandated frequency. In our experience, quarterly reviews for standard roles and monthly reviews for privileged roles are proportionate for most regulated fintechs. Reviews must be documented, assigned to business owners, and acted upon. Yobah configures automated access reviews in Entra ID.

How does zero trust relate to access control compliance?

Zero trust is a security model where no user or device is trusted by default, regardless of network location. Every access request is verified against identity, device compliance, location, and risk signals. For FCA-regulated fintechs, Yobah builds zero trust access models on the Microsoft Entra and Intune stack.