Start by inventorying the systems that hold users, roles, entitlements, and grants in relational databases, then map those fields into a common governance schema. That gives IAM and IGA teams visibility before they try to automate changes, which is the right sequence when legacy apps cannot expose standard integration paths.
Why SQL Tables Change the Starting Point for Identity Work
When identity data lives only in SQL tables, the problem is not just integration, it is discovery, semantic mapping, and control over change. Teams need to identify where the source tables reside, which columns represent users, roles, entitlements, and grants, and how those records relate across applications before they can decide whether the data supports governance, provisioning, or both.
That matters because legacy applications often store identity state in ways that are locally meaningful but operationally ambiguous. A field may look like a role, yet function like a permission bundle, an entitlement flag, or an application-specific grant. Identity Data Quality and Identity Fabric Guide is useful here because it reinforces the idea that authoritative sources and attribute quality have to be understood before identity data can be safely reused elsewhere.
Once teams can describe the data in a common schema, they can separate visibility from automation. Visibility means they can answer basic questions such as who has access, where the data is authoritative, and what is missing. Automation comes later, after the schema is stable enough that downstream changes do not create inconsistent provisioning or revocation behaviour.
How to Map Database-Resident Identity Data Without an API
The practical move is to build a translation layer around the relational source instead of forcing the legacy system to behave like a modern identity service. That usually means cataloguing the tables, documenting primary keys and join paths, and defining a canonical model for identity, entitlement, and relationship data that IAM and IGA tools can consume.
This is also where teams should distinguish between read access and write control. Many environments can safely start with extraction, correlation, and reporting even when they cannot yet automate updates. When write-back is required, the safest path is to introduce tightly governed jobs, stored procedures, or middleware that enforce validation and auditability rather than direct ad hoc database writes.
Identity Visibility and Intelligence Platforms (IVIP) Guide supports this sequence well because the core need is unified visibility across fragmented identity records, not immediate lifecycle automation. For teams working with older platforms, that distinction avoids the common mistake of trying to provision before they can reliably interpret the source data.
In some environments, the right interim architecture is a scheduled feed or ETL process into an identity warehouse or governance layer. In others, change data capture may be better if the source tables are volatile and near real time access reviews depend on fresher state. The deciding factor is not elegance, but whether the chosen path preserves data fidelity and recovery options.
What Good Governance Looks Like Before Automation Starts
Good governance means the organisation can explain ownership, freshness, and meaning for each identity attribute before any automated action is trusted. The teams involved should know which source system is authoritative for each field, how often it changes, who can approve changes, and what evidence exists when a record is corrected or revoked.
For relational identity sources, this often requires a phased operating model: inventory first, semantic mapping second, reconciliation third, then controlled automation only where the data proves stable. Identity Security Programme Guide is a helpful companion because it treats identity work as a programme with scope, ownership, and roadmap decisions, not just a tooling exercise.
Teams should also decide where exceptions live. If a legacy app cannot expose standard integration paths, document whether manual review, batch reconciliation, or database-level controls are the permanent answer. That decision matters because the wrong assumption, that every source will eventually become API-driven, tends to delay controls that could already reduce risk.
Risk and Threat Considerations
Database-only identity stores create exposure when teams cannot see stale entitlements, orphaned accounts, or hidden privilege changes until after they have already propagated. The larger the estate, the more likely it is that incomplete inventory and weak semantics turn into access review gaps or incorrect revocation decisions.
Failure mechanism: identity fields are extracted without a stable canonical model, so the organisation confuses users, roles, grants, and permissions or automates against the wrong attribute. That can preserve excessive access, break deprovisioning, or create inconsistent records across downstream systems.
Impact: access decisions lose reliability, audit evidence becomes harder to defend, and compromised or stale database records can persist long enough to create privilege abuse or operational disruption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity records and grants in SQL need controlled lifecycle handling and revocation discipline. |
| AC-6 — Least Privilege | Legacy identity tables often expose excessive access if grants are not mapped and constrained. | |
| AU-2 — Event Logging | Database-based identity changes need auditable records when automation is absent or partial. | |
| Recommendation — Manage identity credentials and related records with controlled issuance, rotation, and revocation. Limit database and downstream access to the minimum rights needed for each function. Log identity-data access and changes so governance teams can trace updates and exceptions. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Teams must locate every database holding identity data before mapping or governing it. |
| A.5.12 — Classification of information | Identity fields in tables need classification before reuse, extraction, or replication. | |
| Recommendation — Maintain a complete inventory of systems and tables that store identity state. Classify identity data elements before moving them into governance or automation workflows. | ||
Practitioner Guidance
What to prioritise: inventory the tables and joins that actually define identity state before you worry about integration patterns. If you cannot name the authoritative source for a user, role, or grant, you are not ready to automate lifecycle actions.
What to verify: test a small sample of records end to end and confirm that the same identity meaning survives extraction, mapping, and reporting. Pay attention to ambiguous fields such as status flags, role codes, and relationship tables, because those are where misclassification usually starts.
Decision rule: if the source is readable but not safely writable, use it first for visibility, reconciliation, and exception management. If changes must be written back, require governed jobs and audit trails, not direct human edits to SQL tables.
Practitioner takeaway: legacy identity data should be governed as a source of truth problem before it is treated as an automation problem; the safer sequence is discover, normalise, then control.