Soffid for Finance

DORA's ICT risk framework expects a documented, board-approved governance structure reviewed at least annually — for identity specifically, that means demonstrable policies for access provisioning, periodic access review and certification, segregation-of-duties enforcement, and privileged access controls, backed by logs detailed enough to reconstruct who had access to what system at any point in time, not just whether MFA was enabled. Auditors under DORA increasingly expect continuous evidence rather than point-in-time snapshots, so the practical bar is an identity system that can produce a defensible access history on demand, not just at renewal time.

Since DORA makes the management body personally accountable and explicitly bars full delegation to the CISO, the reporting an identity platform needs to surface has to be readable at board level: aggregate risk indicators such as percentage of certified access, outstanding segregation-of-duties conflicts, privileged accounts without recent review, and third-party access exposure — not raw technical logs. The goal is a small set of governance metrics the board can actually interpret and sign off on, with the underlying technical detail available to support it if challenged, not the other way around.

Governance doesn't require touching the mainframe application itself — it requires an identity layer that can read and enforce access at the account/entitlement level on the mainframe's own security manager (RACF, ACF2, Top Secret, or equivalent) and reconcile it against your central identity model, typically through connectors built for exactly this purpose. This brings certification, segregation-of-duties checks, and deprovisioning to mainframe accounts without a replatforming project, treating the mainframe as one more governed system rather than a blind spot outside IAM's reach.

PSD2's strong customer authentication rules are squarely about customer-facing channels, but DORA's ICT risk and governance requirements are broader and explicitly cover internal ICT systems — meaning employee and admin access to core banking, trading, and back-office systems falls within scope too. In practice this means the same rigor applied to customer authentication (logging, access review, incident traceability) needs to extend to internal privileged and administrative access, which is often the weaker link precisely because it predates modern regulatory attention.

Segregation of duties in financial services has to be modeled as rule sets that flag toxic combinations — a trader who can also approve settlements, or an IT admin with both application-config and data-export rights — and these rules multiply fast as systems and roles grow, which is why manual spreadsheet-based tracking breaks down. What satisfies an external auditor is a documented rule set, continuous automated detection of violations rather than only at review time, and an evidenced remediation or formally accepted-risk trail for any exception — auditors care less about zero conflicts than about proof every conflict was identified and consciously handled.

The difference is structural: continuous evidence means access certifications, segregation-of-duties checks, and privileged account reviews run on an ongoing cycle so records are always current, while the fire-drill model means compliance teams reconstruct months of access history under time pressure before each exam, often pulling data manually from systems that don't agree with each other. Teams running the continuous model report far less peak-load strain per audit cycle because the evidence already exists — the cost shifts from periodic crisis effort to steady operational overhead, which is generally the cheaper and less error-prone path over a year.

DORA's third-party risk provisions expect financial institutions to govern outsourced and cloud-provider access to the same standard as internal access — meaning external personnel need identifiable accounts rather than shared credentials, time-bound access tied to the contract or service period, and inclusion in the same certification and audit trail as employees. This typically means extending your identity governance model to cover third-party identities as a distinct but equally governed population, since DORA holds the institution accountable for third-party access even though the provider's staff aren't your employees.

Yes — the common approach is a privileged access management layer that sits in front of the legacy application's shared account, requiring individual users to check out credentials through it, which then logs exactly who used the shared login and when even though the application itself still only recognizes one generic account. This gives you individually attributable access and session recording without modifying the legacy application at all, which is generally the only realistic option when the app predates per-user account models and can't be rewritten.