Lesson 24.4: Access Control Systems

Where This Lesson Fits

Lessons 24.2 and 24.3 established what controls are required — segregation of duties and dual authorization — and made clear that system-enforced controls are categorically more reliable than policy-only controls. But neither lesson examined how system enforcement actually works: what mechanisms determine whether a given user can perform a given function in a given system, how those mechanisms are configured and maintained, and how their operation is monitored and audited. That is the subject of this lesson.

Access control systems are the technology layer that makes system-enforced SOD and dual authorization possible. They determine who can log in, what they can see, what they can do, and what record of their actions is created. Without well-designed and actively managed access control systems, the SOD and dual authorization frameworks from the preceding lessons exist only on paper. This lesson examines access control systems from an operations management perspective: not the technical implementation details that belong to IT, but the design principles, provisioning lifecycle, monitoring requirements, and control failure patterns that operations professionals and compliance officers need to understand.

Lesson Objective

By the end of this lesson, students should be able to describe the three core components of access control — authentication, authorization, and audit — and explain the role of each; explain the role-based access control model and how it implements SOD requirements through system configuration; describe the principle of least privilege and how it constrains access grants to operational necessity; explain the access provisioning lifecycle including request, approval, provisioning, periodic review, and termination; identify the most common access control failure modes in wealth management operations and the controls that address each; explain what an audit log must contain to support both operational monitoring and regulatory examination; describe the specific controls required for privileged access — access with administrative rights that can modify system configurations, audit logs, or other controls; and evaluate the access control adequacy of a described operational environment.

Lesson Overview

Access control systems in wealth management operations serve three distinct functions that are individually necessary and collectively sufficient to enforce the control objectives established in Lessons 24.2 and 24.3. Authentication determines who is present at the keyboard — verifying that the person accessing the system is who they claim to be. Authorization determines what the authenticated user is permitted to do — which accounts they can view, which transactions they can initiate, which functions they can approve. Audit creates an immutable record of what the authenticated user actually did — every action, with identity and timestamp, retained for subsequent review.

The failure of any one of these three functions undermines the others. Strong authentication is defeated if authorization is overly permissive — the right person is logged in but can do more than they should. Strong authorization is defeated if authentication is weak — the access rights are correctly configured but a fraudster has stolen credentials and is now using them. Strong authentication and authorization together are undermined if the audit log is inadequate, manipulable, or not reviewed — the access system is working correctly but no one can reconstruct what happened when a dispute or examination arises.

The role-based access control model (RBAC) is the predominant approach to authorization design in wealth management systems. In RBAC, access rights are assigned to roles rather than individuals; individuals are then assigned to roles based on their job responsibilities. This approach separates the problem of defining what each role should be able to do (a risk management and compliance exercise) from the problem of determining which roles each individual should hold (an HR and management exercise). It also enables SOD enforcement: if two roles have been defined as incompatible, the system can be configured to prevent any individual from holding both simultaneously.

Why This Matters in Wealth & Asset Operations

Access control failures are among the most significant sources of operational risk in wealth management. They enable both internal misconduct (an employee accesses accounts outside their assigned scope, initiates unauthorized transactions, or modifies audit logs to conceal prior actions) and external attacks (compromised credentials are used to access client account systems and initiate fraudulent transactions). The 2023 and 2024 SEC examination priorities both specifically highlighted access management as a focus area, citing inadequate user access reviews, excessive privileged access, and inadequate authentication controls as recurring deficiencies.

The consequences of access control failures extend beyond the immediate transaction. When a client account is accessed without authorization, the firm may have reporting obligations under state and federal data breach notification laws, SEC cybersecurity disclosure rules, and customer notification requirements. When an employee uses system access to commit fraud, the firm's liability extends to the client for the full amount of any unauthorized transactions — regardless of whether the firm had reasonable controls in place, if those controls were not operating. Access control is therefore simultaneously an operational risk management requirement, a cybersecurity requirement, and a regulatory compliance requirement.

Core Concept

Authentication — The process of verifying that a user is who they claim to be before granting system access. Authentication relies on one or more of three factors: something the user knows (password, PIN), something the user has (hardware token, authenticator app, smart card), and something the user is (biometric verification). Single-factor authentication — password only — is considered inadequate for access to systems containing client financial data or transaction processing capability. Multi-factor authentication (MFA), requiring at least two factors, is the current standard for all wealth management operational systems.

Authorization — The determination, after authentication, of what the authenticated user is permitted to do within the system. Authorization in modern wealth management systems is implemented primarily through role-based access control (RBAC): each user is assigned one or more roles, each role carries specific permissions (view account, initiate wire, approve wire, modify account record, generate report), and the system enforces the permission set associated with the user's roles whenever they attempt an action.

Audit Log — An immutable, timestamped record of every action performed within the system, capturing the user identity, the action performed, the data affected, the timestamp, and the outcome. Audit logs are the primary detective control for access control systems: they reveal unauthorized access, inappropriate actions within authorized access, and modification of access rights or system configurations. Audit logs must be retained for periods specified by regulatory requirements (typically three to seven years for transaction-related records) and must be protected from modification by anyone other than authorized security administrators.

Principle of Least Privilege — The access control design principle that each user should be granted the minimum access rights necessary to perform their job responsibilities, and no more. Least privilege minimizes the potential damage from compromised credentials (an attacker who gains access has a limited footprint) and from insider misuse (an employee can only access what they have a legitimate reason to access). In practice, applying least privilege requires regularly reassessing whether current access grants remain appropriate as job responsibilities change.

Privileged Access — System access that grants administrative rights beyond those required for normal operational activity — rights to modify system configurations, grant or revoke other users' access, view or modify audit logs, or access data across the entire system regardless of normal access scope restrictions. Privileged access is the highest-risk access category and requires the most stringent controls: strict least-privilege justification, dual authorization for privileged account use in many environments, enhanced logging, and regular review.

The Access Provisioning Lifecycle

Access provisioning is not a one-time event at employee hire but an ongoing lifecycle with distinct phases, each with specific control requirements. Managing this lifecycle is a joint responsibility of IT (which configures and maintains the technical access mechanisms), HR (which initiates and terminates access based on employment status), management (which specifies required access based on job responsibilities), and compliance or risk management (which reviews access grants against SOD requirements and the principle of least privilege).

• Request and Justification — Access grants begin with a formal request that identifies: which systems and roles are being requested, the business justification for each requested role, the approver who has confirmed the access is appropriate for the employee's job responsibilities, and the SOD review confirming that the requested roles do not conflict with roles the employee already holds. Access requests without documented justification and approval create a governance gap: the firm cannot explain after the fact why access was granted or demonstrate that it was appropriate.
• SOD Conflict Review — Before any new access is provisioned, the requested roles must be compared against the employee's existing roles for SOD conflicts. This review is typically supported by the SOD matrix developed in the context of Lesson 24.2. If the requested access creates a conflict with existing access, the conflict must be resolved — either by removing the conflicting existing access or by documenting a compensating control — before the new access is provisioned.
• Provisioning — After documented approval and SOD clearance, access is provisioned by IT with the minimum role set required. The provisioning event is logged: which access was granted, by whom, when, and under which approval. In organizations with identity management platforms, provisioning is automated based on approved access requests, creating a direct, auditable link between the approval and the access grant.
• Periodic Review — All access grants are reviewed at least annually (and upon any role or organizational change) to confirm that current access remains appropriate. The review process compares current access against current job responsibilities, identifies access accumulated from prior roles that was not removed at transition, and confirms that no SOD conflicts have developed since the last review. Periodic review findings must be acted on: access identified as inappropriate must be revoked promptly, not deferred to the next review cycle.
• Modification and Revocation — When a staff member changes roles, access appropriate to the former role must be revoked at the same time that access appropriate to the new role is granted. Revocation at role transitions is the single most important access provisioning control gap prevention mechanism. When a staff member is terminated, all access must be revoked on the day of termination — and for high-risk positions, prior to the employee's notification of termination. Access that survives termination creates an immediate unauthorized access risk that is both a security incident and a regulatory concern.

Multi-Factor Authentication and Privileged Access Management

Two specific access control mechanisms deserve detailed attention because of their direct relevance to wealth management operations security: multi-factor authentication as the authentication standard for all operational systems, and privileged access management as the specialized control framework for the highest-risk access category.

• Multi-Factor Authentication (MFA) — MFA requires users to verify their identity using at least two independent factors before access is granted. The most common implementation in wealth management is a password (knowledge factor) combined with a time-based one-time password (TOTP) from an authenticator app or hardware token (possession factor). MFA dramatically reduces the risk of credential compromise: even if an attacker obtains a user's password through phishing or data breach, they cannot access the system without also possessing the second factor device. MFA should be required for all access to systems containing client data or transaction processing capability, with no exceptions for convenience. Remote access (from outside the firm's network) requires MFA as a baseline minimum; additional controls (VPN, network segmentation) are typically also required.
• Privileged Access Management (PAM) — Privileged accounts — accounts with administrative rights to modify system configurations, grant access to others, or view all data regardless of normal scope restrictions — require controls beyond those applied to standard operational accounts. PAM frameworks include: requiring privileged account requests to be justified and time-limited (access is granted for a specific task and revoked when complete rather than maintained permanently); requiring dual authorization for privileged account use in high-risk contexts; logging all privileged account actions to a separate, protected audit log that the privileged user cannot modify; and conducting more frequent reviews of privileged account holders than standard account reviews. The most significant access control risk in most organizations is over-privileged accounts: accounts that were granted administrative rights for a specific purpose and never had those rights reduced when the purpose was completed.
• Service Accounts and Shared Accounts — Automated processes and integrations between systems often use service accounts — credentials not associated with a specific human user — to authenticate between systems. Service accounts present a specific control challenge: they often have broad access rights (to enable the integration functions they perform), they are not associated with a specific individual who can be held accountable for their use, and their passwords are rarely rotated because doing so requires updating all integrations that use them. Service account management — documenting what each service account does and why it has its current access, ensuring their passwords are rotated on a defined schedule, and monitoring their activity for anomalies — is a frequently overlooked area of access control that is increasingly a regulatory examination focus.
• Client-Facing Portal Authentication — Wealth management firms that offer client-facing portals (account view, transaction submission, document access) must also manage the authentication controls for client access, not just staff access. Client portal authentication should require MFA for all transaction-capable sessions, enforce session timeouts after defined periods of inactivity, and alert the firm to authentication anomalies (multiple failed attempts, access from unusual locations) for review. The firm bears responsibility for the security of the client authentication mechanisms as part of its overall obligation to protect client assets and data.

Preventive vs. Detective Functions of Access Control Systems

Access control systems serve both preventive and detective control functions simultaneously, and understanding which function each component serves is important for evaluating control completeness.

The preventive function of access control is the authentication and authorization layer: it prevents unauthorized users from accessing systems (authentication) and prevents authorized users from performing functions outside their designated scope (authorization). These preventive controls stop access violations before they can affect client accounts or system integrity. Their effectiveness depends on the strength of authentication credentials (MFA vs. password-only), the precision of role definitions (broad roles that grant excessive access vs. narrow roles that apply least privilege), and the ongoing maintenance of access grants (removing access that is no longer appropriate).

The detective function of access control is the audit log and its review. Audit logs record what actually happened in the system — including actions that the authorization layer should have prevented but didn't (because a role was misconfigured), actions within the user's authorized scope that appear anomalous (a user who is authorized to view client accounts has accessed 300 accounts in a single day), and access by service accounts or unusual login patterns that may indicate compromised credentials. The audit log's detective value is entirely dependent on it being reviewed: a perfect audit log that no one reads is not a functioning detective control.

Operational Workflow: New Employee Access Provisioning

The following describes the complete access provisioning workflow for a new operations staff member joining a wealth management firm, from offer acceptance through first day of access.

1. Access Request Submission. The hiring manager submits an access request form specifying the employee's role, start date, and the specific systems and roles required for their position. The request references the job description and identifies which functional category (initiator, approver, recorder) the employee will fill. The request is not a blanket "give them what the last person in this role had" instruction — it is a specific access list justified by current job responsibilities.
2. SOD Review. The compliance or risk function reviews the requested access list against the SOD matrix. For a new hire with no existing access, the review confirms that the requested roles do not include incompatible combinations (e.g., both initiator and approver for the same transaction type). If the request includes conflicting roles, it is returned to the hiring manager for revision or justification before provisioning proceeds.
3. Approval. The access request is approved by the hiring manager and the compliance function. For privileged access requests, a second approver (typically the IT security officer or the firm's principal) must also approve. Approval is documented in the access management system with each approver's identity and timestamp.
4. Provisioning by IT. IT provisions the approved roles in each applicable system. The provisioning event is logged in the access management system with the provisionor's identity, the roles granted, and the timestamp. MFA enrollment is completed as part of the provisioning process — no access is active until MFA is configured and tested.
5. Access Confirmation and Testing. The new employee confirms that access is functioning as expected and that they can perform their required functions. Any access issues (roles missing, MFA not working) are reported to IT for resolution. The hiring manager confirms that access granted matches the approved request.
6. First-Day Access Briefing. The new employee receives a briefing on the firm's access control policies: what their access permits them to do, what is explicitly prohibited (accessing accounts outside their assigned scope, sharing credentials, using another employee's session), how to report suspected security incidents, and the consequences of access policy violations. The employee signs an acknowledgment.
7. 30-Day Post-Hire Review. The compliance function performs a 30-day review of the new employee's access against their actual activity logs. The review confirms that actual activity is consistent with the scope of the granted access and that no anomalies suggest the access grant was too broad. Any concerns are addressed before the 30-day review closes.

Real-World Example

An SEC examination at a mid-sized investment adviser focuses on the firm's access control environment. The examiners request an export of all current user access grants across the firm's three primary operational systems: the portfolio management system, the wire processing system, and the client relationship management platform.

Review of the access export reveals the following: (1) A staff member who left the firm eight months ago still has active credentials in the portfolio management system — her termination was not communicated to IT, and her access was never revoked. (2) Three operations staff members hold both initiator and approver roles in the wire processing system, as a result of access accumulation through two system upgrades over the prior two years. (3) A shared "reporting" account used by multiple staff members has full view access across all client accounts with no individual user accountability. (4) The IT administrator account, used for system configuration, has the same password it was assigned when the system was implemented four years ago and has never been subject to rotation. (5) The access log review function in the wire processing system is accessible to operations staff — including the same staff with initiator/approver conflicts — rather than being restricted to compliance and IT.

The examination results in five separate deficiency findings: terminated employee access not revoked (remediation: immediate revocation and a process review to prevent recurrence); SOD conflicts in wire processing (remediation: access restructuring and compensating review of all wires processed by conflicted users in the prior two years); shared accounts without individual accountability (remediation: replace with individually attributed accounts for each user); stale privileged account credentials (remediation: immediate rotation and a quarterly rotation schedule); and unrestricted access to audit logs (remediation: restrict audit log access to compliance and IT only, with a dual-approval process for any modification).

Common Mistakes

Mistake 1: Failing to Revoke Access Upon Termination

Terminated employees with active system credentials represent an immediate unauthorized access risk. The risk is not hypothetical: terminated employees — particularly those terminated involuntarily — have used residual access to exfiltrate client data, sabotage records, or initiate fraudulent transactions. Access revocation on the day of termination is a non-negotiable minimum; for involuntary terminations of staff with high-risk access (wire processing, system administration), access should be revoked before the employee is notified. The revocation workflow must be integrated with the HR termination process, not dependent on a separate notification from HR to IT.

Mistake 2: Using Shared or Generic Accounts

Shared accounts — a single set of credentials used by multiple individuals, such as an "ops_team" login — eliminate individual accountability from the audit log. When a transaction is initiated under a shared account, it is impossible to determine which individual performed the action without corroborating evidence. Shared accounts undermine every detective control that depends on audit log attributability. All operational access must be individually attributed: each user has their own credentials, and those credentials are used only by that user. Sharing credentials is a policy violation regardless of convenience.

Mistake 3: Not Restricting Access to Audit Logs

An audit log that can be modified by the users whose actions it records is not a reliable audit trail. The primary scenario in which this matters is insider fraud: an employee who misappropriates client assets may also attempt to delete or modify the audit log entries that would reveal the misappropriation. Audit logs must be accessible for read-only review by authorized compliance and audit personnel, but modification must require IT security administrator access with its own separate audit trail. Operational staff, including senior operations managers, should never have write access to audit logs.

Mistake 4: Provisioning Access Based on Prior Role Templates Instead of Current Needs

New employees are frequently given the same access as the last person who held their role, without reassessing whether that access is still appropriate or whether the prior person had accumulated access beyond what was originally intended. The "copy prior role" approach to access provisioning perpetuates and compounds access creep over time. Every access provisioning event — for both new hires and role changes — must begin with the current job responsibilities and minimum-necessary access standard, not with a template that may reflect access accumulated over years of policy drift.

Mistake 5: Treating the Annual Access Review as a Checkbox Rather Than a Control

Annual access reviews are only valuable if they produce actionable results — if access identified as no longer appropriate is actually revoked, if SOD conflicts identified are actually remediated, and if the review findings are documented and tracked to closure. Annual reviews that produce a list of issues but result in no revocations or remediations — because revocation is operationally disruptive and no one enforces follow-through — are not functioning detective controls. The access review is a detective control; it is the follow-up revocation and remediation that converts the finding into a correction.

Practical Exercises

Exercise 1: Access Grant Analysis

The following users have access in a wealth management firm's wire processing system. For each user, evaluate whether the access grant is consistent with the principle of least privilege, identify any SOD conflicts, and specify the remediation required: (a) User A (Operations Specialist, initiator): holds roles of wire-initiator, account-viewer, and report-generator. (b) User B (Operations Manager, approver): holds roles of wire-approver, wire-initiator (residual from prior role), account-modifier, and user-provisioner. (c) User C (Compliance Officer): holds roles of audit-log-viewer, report-generator, and account-viewer. (d) User D (IT Administrator): holds roles of system-configurator, audit-log-modifier, user-provisioner, and wire-initiator. (e) User E (former Reconciliation Analyst, terminated 60 days ago): holds roles of reconciliation-submitter and account-viewer. For each user where access is inappropriate or conflicted, specify exactly which roles should be revoked and, where applicable, what compensating control should be in place while remediation is completed.

Exercise 2: MFA Implementation Gap Analysis

A wealth management firm currently has the following authentication configuration: (a) In-office access to the portfolio management system requires username/password only. (b) Remote access to the wire processing system requires username/password plus a VPN with a hardware token. (c) Client portal access for transaction submission requires username/password only, with no MFA. (d) The IT administrative console requires username/password only, with a 90-day password expiration. Evaluate each access point against current MFA standards for wealth management operations, identify which configurations are inadequate, describe the specific risks each inadequacy creates, and specify the minimum authentication requirements that should be implemented for each.

Exercise 3: Audit Log Review Scenario

A compliance officer is reviewing the wire processing system audit log for the prior month as part of regular monitoring. She identifies the following entries: (a) User B (operations manager, approver) initiated and approved three wires on a date when both operations initiators were out of the office. (b) User D (IT administrator) accessed the wire processing transaction records for all client accounts on a Saturday afternoon, outside normal business hours. (c) User A (operations specialist, initiator) accessed 47 different client accounts in the portfolio management system over a two-hour period, while only 12 of those accounts have active wire instructions. (d) The audit log shows a 4-hour gap in entries during a Wednesday afternoon, which is inconsistent with normal transaction volume. For each finding, describe what the finding suggests, what the compliance officer should do in response, and what additional investigation would be needed before a determination can be made about whether a control failure or misconduct occurred.

Exercise 4: Termination Access Revocation Protocol

Design a complete access revocation protocol for staff terminations at a wealth management firm. The protocol must address: (a) the trigger for access revocation (notification from HR, end of last day, or pre-termination for involuntary separations); (b) which systems must have access revoked and in what order; (c) who is responsible for executing each revocation step; (d) how revocation is confirmed and documented; (e) how the firm handles the period between termination notification and actual revocation for voluntary separations who provide notice; (f) what to do if systems cannot immediately revoke access (e.g., a vendor system requiring a ticket process); and (g) how the firm would investigate and respond if it discovered that a terminated employee's access had not been revoked for an extended period.

Key Terms

Authentication — The process of verifying a user's claimed identity before granting system access. Modern standards require multi-factor authentication for systems containing client financial data or transaction capability.

Authorization — The determination, after authentication, of what the authenticated user is permitted to do within the system. Implemented through role-based access control in modern wealth management systems.

Audit Log — An immutable, timestamped record of every action performed within the system, capturing user identity, action, data affected, and outcome. The primary detective control for access control systems.

Role-Based Access Control (RBAC) — An access management model in which permissions are assigned to roles and users are assigned to roles. Enables SOD enforcement by configuring incompatible roles so they cannot coexist in a single user account.

Principle of Least Privilege — The design principle that each user should be granted the minimum access rights necessary to perform their job responsibilities, and no more. Minimizes the impact of compromised credentials and insider misuse.

Multi-Factor Authentication (MFA) — Authentication requiring verification of at least two independent factors: something known, something possessed, or something inherent to the user. The current standard for all systems containing client financial data or transaction capability in wealth management.

Privileged Access — System access granting administrative rights beyond normal operational scope, such as the ability to modify system configurations, grant or revoke other users' access, or view all data regardless of normal scope restrictions.

Privileged Access Management (PAM) — A specialized framework for controlling, monitoring, and auditing privileged account use, including time-limited access grants, dual authorization requirements, and enhanced logging.

Access Provisioning Lifecycle — The full sequence of access management events: request and justification, SOD review, approval, provisioning, periodic review, modification at role changes, and revocation at termination.

Access Creep — The accumulation of access grants over time as an employee changes roles, retaining access from prior roles that was never removed. The primary cause of SOD conflicts identified in access reviews.

Service Account — System credentials used by automated processes or system integrations rather than by a human user. High-risk due to broad access rights, lack of individual accountability, and infrequent password rotation.

Session Timeout — An automatic termination of an authenticated session after a defined period of inactivity, requiring the user to re-authenticate. Prevents unauthorized use of an unattended, already-authenticated session.

Knowledge Check

Question 1

An employee logs in with her username and password to the wire processing system and then receives a six-digit code on her authenticator app that she must enter before access is granted. This is an example of:

• A. Single-factor authentication using two steps
• B. Multi-factor authentication, combining a knowledge factor (password) with a possession factor (authenticator app)
• C. Dual authorization, requiring two people to approve access
• D. Role-based access control enforcement

Correct Answer: B — The password is a knowledge factor (something the user knows) and the authenticator app generating the one-time code is a possession factor (something the user has). Requiring both is multi-factor authentication. This is distinct from dual authorization, which requires two people for transaction approval, not for system login.

Question 2

During an annual access review, it is discovered that an operations specialist who moved to a client service role six months ago still has wire initiator access in the wire processing system. What is this condition called and what is the immediate required action?

• A. A provisioning error requiring a review of IT's access management procedures; no immediate action on the access itself
• B. Access creep — accumulated residual access from a prior role; the wire initiator access must be revoked immediately and the prior six months of wire activity reviewed for any wires she both initiated and processed
• C. An acceptable overlap since the employee may occasionally need to initiate wires in her client service capacity
• D. A duplicate account that should be merged with her current access profile

Correct Answer: B — Access creep occurs when residual access from prior roles is not removed at role transition. The immediate action is revocation of the no-longer-appropriate access and a review of the period during which the access was active to identify any activity that should not have occurred. Assuming the access is acceptable because the employee might occasionally need it undermines the principle of least privilege and the SOD design that assigned initiator access only to current wire initiators.

Question 3

Why are shared accounts (multiple users sharing the same set of credentials) a control problem in wealth management operations?

• A. Shared accounts are more likely to be compromised by external attackers because passwords are known by multiple people
• B. Shared accounts eliminate individual accountability from the audit log — it is impossible to determine which individual performed an action under the shared account, undermining every detective control that depends on attributable audit records
• C. Shared accounts typically have too many permissions because they are designed for multiple use cases
• D. Regulatory requirements prohibit shared accounts for all purposes

Correct Answer: B — The fundamental problem with shared accounts is the elimination of individual accountability. While A and C may also be true, the most significant control failure from shared accounts is that the audit log becomes uninformative: "the ops_team account initiated this wire" tells you nothing about which individual was responsible. This defeats reconciliation, investigation, and accountability for any transaction or access event performed under the shared account.

Question 4

An IT administrator has had the same privileged account password for three years. She uses this account to modify system configurations and can also access and modify the audit logs. What are the two most significant control failures in this scenario?

• A. Password age and the ability to modify audit logs
• B. The IT role itself and the system configuration access
• C. The lack of MFA and the single-factor password
• D. The annual review cycle and the access provisioning timeline

Correct Answer: A — A three-year-old privileged account password is a significant authentication risk: if the credentials were compromised at any point (through data breach, phishing, or insider access) in the prior three years, an attacker has had ongoing privileged access. More critically, the ability to modify audit logs means the IT administrator can conceal her own actions — a fundamental breakdown of the separation between operators and those who audit them. These two issues together create a scenario where a sophisticated insider can act without detection.

Question 5

An employee who has been terminated returns her access badge and laptop on her last day, but IT does not receive the termination notification until three days after her departure. During those three days, her system credentials remain active. What is the most important immediate action when IT receives the notification?

• A. Revoke her credentials immediately and review the audit log for all activity under her credentials in the three days since her departure
• B. Revoke her credentials at the next scheduled access review
• C. Send her a notification confirming that her access will be terminated within 30 days
• D. Change only her password to prevent remote access while the revocation process is completed

Correct Answer: A — Credential revocation is immediate upon receiving termination notification — not deferred to a review cycle. The three-day gap during which her credentials were active is an unauthorized access period that requires audit log review to determine whether any system access occurred. This is not an administrative matter to be handled at convenience; it is a security incident requiring immediate response and documentation.

Lesson Summary

Access control systems provide the technological foundation on which segregation of duties and dual authorization depend. They function through three components that are individually necessary and collectively sufficient: authentication (verifying identity before granting access), authorization (determining what the authenticated user is permitted to do), and audit (creating an immutable record of what was actually done). Failure in any one component undermines the others.

The role-based access control model is the standard implementation for authorization in wealth management systems. It enables SOD enforcement through role configuration and supports least privilege through precise role definitions. The access provisioning lifecycle — request, SOD review, approval, provisioning, periodic review, modification, and termination — must be actively managed as an ongoing process, not configured once and left static.

The most common access control failures in wealth management — terminated employee access not revoked, access creep from role transitions, shared accounts, stale privileged credentials, and audit log modification access — are all addressable through disciplined provisioning lifecycle management, periodic access reviews, and clear ownership of the revocation process. Multi-factor authentication is the minimum standard for all operational systems; privileged access management is required for accounts with administrative rights.

Looking Ahead

Lesson 24.5 examines transaction approval workflows — the end-to-end approval structures that integrate the SOD, dual authorization, and access control principles from the preceding lessons into a coherent authorization framework for each transaction type. Where Lessons 24.2 and 24.3 examined the principles and mechanisms of control, and Lesson 24.4 examined the technological infrastructure, Lesson 24.5 examines how these elements are assembled into an operational workflow that functions reliably at transaction volume.

Study Support

How to Approach This Lesson

Think of access control systems as having three layers that each must be sound. The authentication layer asks: is this really the person they claim to be? The authorization layer asks: is this person permitted to do what they're attempting? The audit layer asks: what did this person actually do, and can we reconstruct it completely? For any access control scenario you evaluate, work through all three layers: where does each one apply, what is each one's current status, and what is the consequence if any layer fails?

Key Patterns to Recognize

• The access provisioning lifecycle is only as strong as its termination step — access that survives termination creates immediate risk.
• Access creep accumulates at every role transition where revocation is not enforced — periodic reviews are the primary detective control.
• Shared accounts are incompatible with attributable audit trails — they must be replaced with individually attributed accounts.
• Audit log integrity requires that the users whose actions are logged cannot modify the log.
• Privileged access requires more controls than standard access, not fewer.

Questions to Test Your Understanding

• Can you explain the difference between authentication and authorization?
• What is the principle of least privilege and why does it matter for SOD?
• What makes an audit log reliable as a detective control?
• What is access creep and how does it occur?
• Why are privileged accounts the highest-risk access category?

Common Areas of Confusion

The most common confusion is between authentication and authorization. Authentication is identity verification — proving who you are. Authorization is permission determination — what you're allowed to do once your identity is confirmed. A user can be strongly authenticated (MFA verified, definitely the right person) but improperly authorized (holding roles that create SOD conflicts or that are broader than their job requires). Both layers must be sound independently. The second confusion involves dual authorization (two people approving a transaction) versus multi-factor authentication (two factors verifying one person's identity). These address different risks: dual authorization addresses the risk of a single person executing an unchecked transaction; MFA addresses the risk of someone impersonating an authorized user.

Practical Application

Application 1: Designing an Access Review Program

Operations compliance officers in wealth management firms typically own the annual access review program, working with IT to pull access exports and with management to evaluate access appropriateness. An effective access review program specifies: the review scope and frequency; the documentation format for review findings; the escalation path for identified conflicts; the timelines for remediation of identified issues; the sign-off requirements that demonstrate the review was completed; and the process for connecting access review findings to the SOD matrix update. In firms subject to SOC 1 audits, the access review program is typically a key control tested by external auditors.

Application 2: Responding to an Authentication Anomaly

When the access monitoring system alerts on an authentication anomaly — multiple failed login attempts followed by a successful login from an unfamiliar IP address, for example — the operations security response follows a defined workflow: suspend the account immediately pending investigation; review the audit log for all actions taken under the account from the suspicious access; attempt to contact the account holder to confirm whether the access was legitimate; if access was unauthorized, escalate to legal and compliance for breach notification assessment; and document the full incident timeline. The speed of the response determines whether any damage from the unauthorized access can be limited — immediate account suspension is the first action, not the last.

Application 3: Integrating Access Controls with New System Implementations

When a wealth management firm implements a new operational system — a new portfolio management platform, a new wire processing system, a new client portal — the access control design must be completed before go-live, not after. This means: defining all required roles and their permission sets; mapping the roles to the SOD matrix and confirming no incompatible combinations are created; configuring the RBAC structure in the system; establishing the audit log parameters and retention settings; enrolling all users in MFA; and testing the access configuration against specific scenarios (can the initiator approve? can the approver access accounts outside their scope?). Access control design is a go-live prerequisite, not a post-launch task.

Application 4: Communicating Access Control Requirements to Staff

Access control effectiveness depends on staff understanding what they are and are not permitted to do with their system access. Operations managers communicate access policies to staff through: initial onboarding briefings that explain the rationale for access restrictions (not just the rules but why they exist); clear policies on prohibited behaviors (sharing credentials, accessing accounts outside assigned scope, using personal devices for work systems without MFA); reporting channels for access anomalies (who to call if you notice you have access you shouldn't have, or if you suspect someone else has accessed your credentials); and consistent enforcement of access policy violations. Staff who understand why access controls exist and who feel safe reporting anomalies are a meaningful component of the access control system.

Lesson Navigation