FinCore Bank: Access Requests Between Speed and Control
At FinCore Bank the service catalog includes 'Grant read access to the customer analytics database'. The entry is marked standard, pre-approved, and auto-fulfilling; average fulfillment is 18 minutes. The database holds PII for 2.1 million customers. An internal audit sampled 60 grants and found 47 where the requester's manager approved without checking the role-based access matrix, 9 where the requester was also the approver, and 4 for contractors whose contracts had ended. Information security runs a separate access-request process with risk scoring; change enablement requires a change record for new access roles but not for individual grants. The SRM owner argues that access requests are 'just requests' and should stay fast. The CISO has frozen all database access requests pending review. Revenue reporting depends on the analytics team, and 30 analysts are waiting for access.
1. Evaluate whether this catalog entry should be standard and pre-approved. Identify the practices that must interface with service request management and the governance controls that were missing.
Read the worked answer
A standard, pre-approved request must be low-risk, common, repeatable, and within policy. Read access to a PII database may be common, but it is not automatically low-risk. If access is strictly role-based and the role matrix is approved by the data owner, a standard request can be appropriate. If each grant depends on the data content, purpose, or contractor status, it is not standard and needs authorization.
The audit findings show the controls failed: managers approved outside their authority, requesters approved themselves, and contractor leavers retained access. That is not evidence that speed is wrong; it is evidence that the entry was misclassified and the approval model was not enforced.
Interfaces: access management owns granting and revoking access and least privilege; information security owns data classification, risk scoring, and policy; change enablement owns changes to access roles and permissions (individual grants usually follow access management, but new roles need change control); supplier management owns contractor status and contractual obligations; HR provides joiner-mover-leaver data. The service request practice orchestrates the request and experience but does not accept the risk on behalf of the data owner.
The SRM owner's 'just requests' framing is the core error: service requests are normal service actions, but 'normal' is defined by policy and risk, not by convenience.
2. Recommend a target decision model that preserves speed for low-risk access while controlling PII risk. Specify who approves, what is automated, and what evidence is retained.
Read the worked answer
Use a tiered model tied to data classification and role.
Tier 1 - role-based standard access. The data owner and security approve the role matrix once. A user in an entitled role requests the role; the system checks entitlement, completion of required training, and employment status, then auto-provisions time-bound access. No per-request manager approval is needed because the decision was made at role design. Evidence: role ID, entitlement check, approval date of the role, and expiry.
Tier 2 - non-standard or broader access. Requires a stated purpose, data owner approval, manager confirmation of business need, and security risk assessment where sensitive. No self-approval. Evidence: justification, data owner decision, risk score, and expiry.
Tier 3 - privileged or sensitive extracts. Adds security approval, stronger authentication, logging, and possibly a change record. Evidence: all Tier 2 evidence plus monitoring acknowledgement.
Automate the checks, not the risk acceptance: policy-as-code for role membership, contractor end dates, and training completion. The catalog entry should display data classification and expected lead time. Retain an auditable record for each grant, and recertify role membership regularly rather than re-approving every request. This keeps the 18-minute path for genuinely standard access while preventing managers from approving what they do not understand.
3. What should the SRM owner do during the CISO's freeze, and how should the practice report to governance afterward?
Read the worked answer
The SRM owner should comply with the freeze, stop auto-fulfillment immediately, and not create shadow exceptions. In parallel, triage the 30 waiting analysts by risk and business need: identify those whose access fits an already approved role, those who need data owner review, and those with no valid business need. Provide the CISO with a clear queue, not pressure to bypass.
Short term: communicate status and expected dates, define an emergency path for revenue-critical reporting with compensating controls (time-bound access, supervision, logging), and support the audit with complete records. Fix the catalog entry so it no longer claims 'standard, pre-approved' until the role matrix and entitlement checks exist.
Medium term: agree the tiered model with the data owner, security, access management, and HR; update the authority matrix; embed contractor end-date checks; run a retrospective review of the 60 sampled grants and revoke inappropriate access.
Governance reporting should include: number of grants by tier, percentage auto-provisioned, approval exceptions, self-approvals (target zero), contractor access past end date (target zero), time to grant for standard versus non-standard, and audit findings with closure dates. Report risk acceptance to the data owner and CISO, not to the service desk. The practice owns the process and evidence; the business data owner owns the risk decision.