Procedures for GLOSS account and permission tickets: joiners, profile changes, leavers, lockouts, auditor access, recertification and segregation of duties.
- Access is granted through predefined profiles per role (settlements officer, corporate actions officer, reconciliation analyst, read-only, support). No ad hoc permission sets.
- Segregation of duties is enforced by the input/release model: whoever inputs an instruction or a static data change cannot release it (four-eyes). Profiles combining input and release on the same scope require an approved exception.
- Every request needs the line manager's approval; sensitive profiles (release rights, static data, security admin) also need the application owner's approval.
- Verify the HR onboarding record and the manager approval.
- Assign the standard profile for the role — "same as colleague X" requests are mapped back to a named profile, never cloned raw (the colleague may have accumulated exceptions).
- Set the market scope and account perimeter; default is the joiner's team perimeter only.
- Create in UAT/Training first if the joiner is new to GLOSS; production access once the team lead confirms training completion.
- Communicate the account name; the initial password follows the standard first-login reset flow.
¶ Profile and perimeter changes
- Change of team = new profile assignment + removal of the old one, not an addition. Accumulated profiles are the main recertification finding.
- Temporary elevation (cover during absence) must carry an end date; a request without an end date is rejected.
- Any change touching release rights or monetary limits requires four-eyes on the security module itself.
¶ Leavers and long absences
- Leaver: disable the account on the last working day (never delete — audit trail), remove from generic mailboxes and report distributions, transfer report ownership.
- Long absence (> 30 days): disable and reactivate on return; recertify the profile at reactivation.
- A leaver holding open items (unreleased instructions, pending elections) → the team lead reassigns them before the account is disabled.
¶ Lockouts and generic accounts
- Account lockout: verify identity via callback or the manager, then unlock; three lockouts in a month → look for a stale saved password in a script or macro.
- Generic/service accounts: a named owner is mandatory, password vaulted, interactive login disabled where possible; each recertification re-approves the owner.
¶ Auditor and temporary external access
- Auditors get read-only profiles, scoped to the audit perimeter, with an end date; extraction rights only via a named sponsor who receives the extracts.
- Quarterly campaign: managers confirm each account, profile and scope. Non-responses are disabled after the deadline — no exceptions without the application owner.
- Never grant input and release on the same scope to one person without a documented exception.
- No production access without confirmed training.
- Disable, don't delete.
Suspected misuse or shared credentials → security officer immediately. SoD conflict discovered in production → application owner + compliance the same day.