Identity Governance Software for Sports Organisations

A sports organisation's identity data spreads across an identity provider, ticketing, finance, CRM, shared drives, performance platforms and a long tail of specialist vendor applications, most of which were bought by a department rather than by IT.

The hard questions are rarely about logging in. They are governance questions: who has access to the payments system, which users hold admin rights, which contractor accounts expire this month, did every system owner review access last quarter, which new starters are still waiting, and which leavers still have an account in a system nobody remembers buying.

This proposed identity governance software puts one governance layer across those systems. It leaves single sign-on, multi-factor authentication and the identity provider itself exactly where they are.

One access model

Scheduled exports, or live data where an interface exists, feed a single model: person, employment or contract status, department, role, system, account, access level, whether that access is privileged, last login where the system reports it, start and end dates, the system owner, and when each source last refreshed.

The refresh time is part of the answer rather than a footnote. A snapshot presented as live state is how an access report ends up contradicting a system console in front of an auditor.

Asking the model a question

The questions people actually ask are narrow: who currently has access to the finance platform, which external contractors hold admin rights, which accounts have not been used in ninety days, every system one named person can reach.

Answers come back as a table with an export, timestamped with the age of the data behind them. Where a feed failed, the report says which one and when, rather than answering from a stale copy.

Access requests

Someone needing access to a system emails IT, who forward it to whoever they believe owns it, who is on leave, so it is forwarded again. The ticket that results carries none of what an approver needs, and the approval arrives as the word approved in a thread.

A structured request captures the system, the level of access and the business reason, matches the system against the owner directory, and sends that owner a decision to make rather than a message to read. Approval moves the request into a provisioning queue, and the request stays open until someone confirms the access exists and tells the requester.

That last step closes the gap audits find: an account approved but never provisioned, or provisioned but never approved, with no way to tell which without reading the whole thread.

Warehouse schemas and reporting workspaces

The least governed access in most organisations is the access to the data itself. An analyst needs a new schema, or a manager wants a colleague added to a dashboard workspace, so they message whoever set up their own access last time, and that person grants more than was asked because scoping it properly takes longer.

The same request model applies here, with a few additions that matter. The request names the data object or workspace, the access level, the business reason, the data owner and, where the need is temporary, a duration. Approval routes to the named data owner, then to whoever provisions.

Where the platform supports roles, provisioning goes through an approved role rather than a grant on an individual object, which is what makes the later revocation a single clean action rather than a hunt. Requests touching medical, payment or safeguarding data carry an additional review step on the organisation's own rules.

Every approval sets a review date, because analysis access is routinely granted for one project and kept for years. When it falls due, the workflow reopens the decision for renewal or revocation rather than letting it lapse into permanence.

Emergency access happens. The workflow allows an out-of-band grant to be logged and reviewed afterwards, since pretending it never occurs simply moves it somewhere unrecorded.

Permission drift monitoring across data systems

Access governance should detect when intended access and enforced access diverge across systems.

A multi-entity sports organisation may represent clubs, academies, regions or departments in identity-provider groups, warehouse roles or row-level security policies, BI workspace or report sharing, and CRM entity rules.

A scheduled reconciliation can compare these against the organisation's approved entity or access model.

Flag examples:

• Entity exists in the IdP but not the warehouse policy
• Warehouse row-level rule grants a different entity scope than the IdP group
• BI workspace sharing does not match the approved entity mapping
• New club or academy has incomplete provisioning
• Removed entity still has an active reporting rule

The system should show: mismatch, systems involved, intended rule, current rule, owners of each side, age of issue.

It should not automatically "fix" the mismatch in V1 because the software cannot safely assume which side is authoritative when two systems disagree.

Starters, movers and leavers

A starter's role expands against an access template: the systems that role needs, maintained by the service desk and security team rather than reconstructed from memory each time.

Each system becomes one task routed to that system's named owner, confirmed or declined from a link. A status board shows every starter's outstanding items and escalates what has gone untouched. The tasks are the point: the platform tracks who was asked and whether they acted, which is the part email cannot do.

A mover is the case most processes miss entirely. Changing department adds new access and almost never removes the old, and the review that catches it belongs at the moment of the move rather than at the next annual attestation.

A leaver runs the same list in reverse, and deserves a board of its own.

The usual leaver ticket closes when single sign-on stops working, while the CRM, the finance system, a few shared drives and the tool a manager arranged directly with a vendor were never on it. One row per leaver per in-scope system, each with a status of revoked, pending or overdue and a deadline set by policy from the last day of employment, makes the remainder visible. Crossing a deadline escalates to that system's owner rather than to IT in general, and keeps escalating until someone marks it done against their own name.

Nothing is revoked automatically. Confirming an account is off stays a person's job, and the board's contribution is that the job cannot quietly go undone.

Role templates do not maintain themselves. When a system is retired or a role is redefined, someone has to revise the template, and that ownership needs a name against it from the start.

Contractor access

External access carries a sponsor, a start and end date, the systems in scope, and the record of every renewal decision.

Before an end date, the sponsor gets one question with two answers: extend with a new date, or confirm the lapse. An extension records a reason and a new date. A lapse queues deprovisioning for that date. No reply escalates, first to the sponsor's own manager and then to the service desk lead.

Silence never extends access. That is the rule that separates a register from a spreadsheet of dates nobody acts on.

Access reviews and attestation

Periodically, each system owner opens a list of every current user on their system and decides one row at a time: keep, revoke or change, with reviewer, date and comment.

Row by row matters. The emailed spreadsheet asking an owner to confirm a list produces a reply saying it looks fine, and what exists afterwards is a folder of emails rather than a record of which user was checked. A per-user decision produces an attestation report covering every system, every user and every decision, in a form built to hand to an assessor.

A revoke raises a task rather than removing access, because switching access off is a separate job with its own owner. The round closes when those tasks are confirmed, since an attestation that produced a list of revocations nobody performed is worse than none: it is evidence that the organisation knew.

Privileged access and dormant accounts

The organisation defines what counts as privileged: administrator, finance approver, superuser, data export rights, security administration. Those entitlements get their own view and usually their own review cadence.

Privilege comes from configured rules rather than inference from a job title, since the head of a department frequently has no elevated rights and a long-serving analyst frequently does.

Where last login is available, accounts idle past a configured period surface for review. Dormancy is a prompt to ask, rather than evidence that the access should go. Seasonal roles, disaster recovery accounts and integration users all look dormant and are all sometimes correct.

The owner directory underneath it

Every application needs a business owner, a technical owner, an access approver and a review frequency.

That directory is what makes routing possible for starters, reviews and contractor decisions alike, and building it is usually the unglamorous first month of the project. An out-of-date directory sends approvals to people who left, which produces attestations that look complete and prove nothing.

Mismatches stay visible

Sources disagree, and the platform reports the disagreement rather than resolving it quietly: HR says a person left while an account remains, the access register and the application's own export do not match, a user exists in an application but not in the directory, or an export failed and today's picture is last week's.

Silent reconciliation is the failure mode that makes a governance tool dangerous, because it produces a clean report over a dirty estate.

Where it sits next to software asset management

Identity governance answers who should have access and who does. Software asset management answers what the organisation owns, pays for and renews.

They share application identifiers, and each improves the other: a licence with fifty seats and eleven active users is a renewal question, and the eleven are the people an access review needs to look at.