What Are Reconciliation and Provisioning Policies in IBM ISIM? Explained With Real Examples

IBM Security Identity Manager Online Training  (ISIM, now offered as IBM Security Verify Governance): reconciliation and provisioning policies. Reconciliation tells ISIM what actually exists on target systems. Provisioning policies tell ISIM what should exist. Most day-to-day identity governance work comes down to keeping these two in agreement.

This guide explains both concepts in plain language, with realistic examples, common problems, and best practices. It suits beginners, administrators, support analysts, and learners preparing for IBM ISIM online training or interviews. The examples are illustrative composites, not events from any specific company. Screen names and options can vary slightly by ISIM version, so confirm details in your own environment.

A Quick Background: How ISIM Fits Together

Before looking at the two features, it helps to know the main building blocks.

• Person: A record for an individual in the organization, usually loaded from an HR system. Each person has attributes such as name, department, manager, and employment status.

• Service: A representation of a target system that ISIM manages, such as Active Directory, a database, an application, or a Unix server.

• Account: A user ID on a target system, linked to a person (its owner).

• Adapter: The software component that lets ISIM communicate with a particular target system type.

• Role: A grouping of people, often used to assign access based on job function.

• Identity policy: Rules that generate user IDs, for example first initial plus last name.

• Provisioning policy: Rules that define who gets what access.

• Workflow: The approval or processing steps that run behind requests.

ISIM stores its own view of persons, accounts, and policies in its data store. The target systems hold the real accounts. Because administrators and applications can change targets directly, the two views can drift apart. Reconciliation and provisioning policies are the tools that detect and fix that drift.

Part 1: What Is Reconciliation in IBM ISIM?

The simple definition

Reconciliation is the process of pulling account and supporting data from a managed target system into ISIM so that ISIM’s records match what really exists on that system.

Think of it as a periodic inventory count. A store keeps records of its stock, but shelves change through theft, mistakes, and unrecorded deliveries. A stocktake compares the records with the shelves. Reconciliation does this for accounts.

Why reconciliation is needed

Without reconciliation, ISIM only knows about accounts it created itself. In real environments, accounts also appear in other ways:

• A system administrator creates an account directly on a server.

• An application team adds users to a database without raising a request.

• Accounts existed before ISIM was installed.

• A password reset, lock, or deletion happens outside ISIM.

• A script or migration creates or removes accounts in bulk.

Reconciliation brings all of these into view. It is the foundation for audit, cleanup, and compliance.

What reconciliation actually collects

A reconciliation run typically collects two kinds of data:

1. Account data: The list of accounts, their attributes, status, and group memberships.

2. Supporting data: Reference information such as groups, roles, or other objects that the target system uses. This helps ISIM present valid choices on request forms.

Many environments schedule account reconciliation regularly, and supporting-data reconciliation less often because groups change less frequently. Whether and how each is scheduled depends on your design.

How reconciliation works step by step

1. A schedule or a manual action starts the run. Administrators can run it on demand for a service or schedule it daily, weekly, or at another interval.

2. ISIM sends a request through the adapter to the target system, usually with a query or filter that defines which accounts to retrieve.

3. The adapter reads accounts from the target and returns them to ISIM.

4. ISIM compares each returned account with its existing records.

5. For each account, ISIM decides what to do:

• If the account is already known, ISIM updates its stored attributes.

• If it is new and ISIM can match it to a person (for example through an adoption rule), ISIM links it to that owner.

• If it is new and no owner can be found, ISIM treats it as an orphan account.

6. ISIM evaluates the accounts against provisioning policies. Accounts that break policy are marked as noncompliant, and ISIM may take the enforcement action configured for that service.

Key reconciliation concepts

Orphan accounts. An orphan is an account on a target system that ISIM cannot match to any owner. Orphans are a major audit concern, since nobody is accountable for them.

Adoption. Adoption is the process of linking an orphan account to a person. ISIM can do this automatically using adoption rules based on matching attributes, or administrators can do it manually. A common rule is to match the account ID or email address to an attribute on the person record.

Reconciliation queries and filters. A query limits which accounts are retrieved. For example, you may reconcile only accounts under a certain organizational unit in a directory, so a large environment can be processed in smaller parts.

Schedules. Reconciliation can be run on a timetable. A schedule that is too frequent loads the target and ISIM, while one that is too rare leaves the data stale.

Compliance check after reconciliation. The accounts that come back are compared with what provisioning policies say each person should have. This is where reconciliation and provisioning policies meet, which is covered below.

Real example 1: Finding orphan accounts before an audit

A company prepares for an internal audit. The identity team runs reconciliation against its Active Directory service for the first time in months. The result shows several hundred accounts with no owner. Investigation reveals three groups:

• Service accounts created by application teams

• Former contractors whose accounts were never removed

• Test accounts created during an old project

The team creates an adoption plan. Service accounts are assigned to responsible application owners. Former contractor accounts are suspended and later deleted. Test accounts are removed. Without reconciliation, none of these accounts would have been visible inside ISIM.

Real example 2: A direct change on the target system

A database administrator adds a developer to a privileged group directly on a database server to fix an urgent issue. No request exists in ISIM. At the next reconciliation, ISIM reads the account’s group memberships and sees the new privilege. If the developer’s role does not allow that group, the account is flagged as noncompliant. Depending on the enforcement setting, ISIM can mark it for review, suspend it, or correct it.

Real example 3: Reconciliation taking hours

An administrator complains that reconciliation of a large directory runs for hours and sometimes fails. The team reviews the design and splits the work using queries, so different organizational units are reconciled separately and at different times. They also move the heavy runs outside business hours. Runtime drops and failures stop. The lesson is that reconciliation design affects performance, not just correctness.

Common reconciliation problems and causes

Where to look when reconciliation fails

Start with the simplest checks and move deeper:

1. Is the adapter service running on its host?

2. Can ISIM reach the adapter, and is the connection secure and valid?

3. Are the service’s connection details and credentials correct?

4. What do the reconciliation status and error text in the ISIM console say?

5. What do the ISIM application logs show for that time?

6. What do the adapter’s own logs show?

Collect the exact error text and time of failure before escalating. It speeds up diagnosis significantly.

Part 2: What Are Provisioning Policies in IBM ISIM?

The simple definition

A provisioning policy is a rule set that defines which people are entitled to which access on which services, and under what conditions.

If reconciliation answers “what exists?”, provisioning policies answer “what should exist?” They turn business rules such as “all finance staff get access to the accounting application” into automated behavior.

The main parts of a provisioning policy

Every provisioning policy contains a few key elements:

1. Membership (who). This defines who the policy applies to. Options usually include:

• All users

• Specific roles

• Specific people

• Everyone except certain groups

Using roles for membership is the most common and maintainable approach.

2. Entitlements (what). Each entitlement specifies a service, or a type of service, that the members may have an account on. An entitlement can also control:

• Whether the account is created automatically or only on request

• Which attributes get which values

• Whether an approval workflow is needed

3. Entitlement type. Entitlements generally fall into modes such as:

• Automatic: The account is provisioned automatically when someone becomes a member.

• Manual: The person is allowed to have the account but must request it.

• Workflow-based: The request goes through approval steps before provisioning.

4. Parameters (how). Parameters decide attribute values on the account. A parameter can be a fixed value, a value derived from the person’s data (such as department), or the result of a script. Each parameter also has an enforcement type, which defines how strictly ISIM holds the account to that value.

5. Status and priority. Policies can be enabled or disabled and can have priorities, which matter when several policies apply to the same person.

How provisioning policies work

1. A person joins a role, or their attributes change.

2. ISIM evaluates which provisioning policies now apply to that person.

3. For each applicable entitlement, ISIM decides what to do. If it is automatic, ISIM creates the account or updates it with the correct parameters. If it is manual, ISIM makes the access available for request. If it requires approval, ISIM starts the workflow.

4. When the person leaves the role or their status changes, ISIM re-evaluates and can remove or suspend access that is no longer allowed.

This makes access follow the person’s job rather than relying on manual tickets.

Real example 1: Automatic access for a new joiner

A finance analyst joins the company. HR creates the person record, and the person is placed in a “Finance Analyst” role. A provisioning policy for that role includes automatic entitlements for the corporate directory, email, and the finance reporting application. Within minutes of the role assignment, the accounts are created with correct attributes, such as department and default group. No tickets are needed, and the analyst can work on day one.

Real example 2: Manual entitlement with approval

The same company allows finance analysts to request access to a sensitive payments system, but not automatically. The provisioning policy marks this entitlement as workflow-based. When an analyst requests it, the request goes to their manager and then to a system owner. Only after both approve does ISIM provision the account. The audit log records who requested, who approved, and when.

Real example 3: Parameter enforcement

A policy sets the home directory attribute on a server account based on the person’s department. A server administrator later changes one account’s directory manually. At the next evaluation or reconciliation, ISIM sees that the value differs from the policy. Depending on the enforcement type, ISIM can leave it, mark it, or restore the value defined by the policy. This helps keep configuration consistent across thousands of accounts.

Real example 4: Mover scenario

An employee moves from Sales to Procurement. Their role changes in ISIM. The Sales provisioning policy no longer applies, and the Procurement policy now does. ISIM provisions the new access and removes or flags the old Sales access, depending on the policy design. Without this, people collect access over the years, a problem often called privilege creep.

Real example 5: Leaver scenario

When HR marks an employee as terminated, ISIM suspends or deletes the person’s accounts across target systems according to lifecycle rules. If one target system fails, for example because the adapter is down, ISIM can retry or report the failure so the team can fix it. A terminated user who still has access is one of the most serious audit findings, so this scenario is closely monitored.

Part 3: How Reconciliation and Provisioning Policies Work Together

These two features are not separate topics. They form a loop.

The compliance loop in practice

1. Provisioning policies define the rules.

2. Reconciliation reads the target system and shows what accounts and attributes actually exist.

3. ISIM compares them. Accounts that match are compliant. Accounts that do not are noncompliant.

4. ISIM applies the configured enforcement for the service.

5. Administrators review exceptions, adopt orphans, and adjust policies where the business has changed.

Enforcement options

When ISIM finds a noncompliant account, the service’s policy enforcement setting decides what happens. Typical options include:

• Mark: Flag the account as noncompliant for later review, without changing it.

• Suspend: Disable the account until the issue is resolved.

• Undo: Reverse the change that caused the noncompliance where possible.

• Correct: Change the account so it matches policy.

Starting with marking is a safe approach in new environments, so you can review the impact before enabling stricter actions. Suspending or correcting many accounts at once on the first run can disrupt users.

A combined real example

A company enables a new provisioning policy that says contractors may only have standard-user access to a project server, never administrator access. The team then runs reconciliation. ISIM finds eleven contractor accounts with administrator rights. With enforcement set to mark, the accounts are listed as noncompliant. The team reviews each one, confirms that nine were granted by mistake, and corrects them. Two were temporary exceptions, so the team documents an approved exception. Reconciliation made the problem visible, and the provisioning policy defined what “wrong” meant.

Part 4: Common Mistakes and How to Avoid Them

Reconciliation mistakes

• Running reconciliation for the first time with strict enforcement. This can suspend or change many real accounts at once. Start with marking and review.

• No adoption plan. Orphans pile up with nobody responsible. Define matching rules and an owner for exceptions.

• Reconciling everything at peak hours. This slows the target and ISIM. Schedule heavy runs during quiet periods and split large directories with queries.

• Ignoring failed runs. A failed reconciliation can leave data stale for weeks. Monitor results and alert on failures.

• Not reconciling supporting data. Request forms may then show outdated groups or missing options.

Provisioning policy mistakes

• Too many overlapping policies. When several policies give conflicting parameter values, results become hard to predict. Keep policies simple and understand how multiple policies combine.

• Assigning access to individuals instead of roles. This is hard to maintain and audit. Use roles for membership wherever possible.

• Role explosion. Creating a new role for every small difference leads to hundreds of roles that nobody understands. Design roles around real job functions.

• Automatic entitlements for sensitive access. Privileged access normally deserves approval and periodic review.

• Changing production policies without testing. A small mistake in membership or parameters can affect thousands of accounts. Test in a lower environment and review the expected impact first.

• Poor documentation. Without clear notes on why a policy exists, future administrators fear to change or remove it.

Part 5: Best Practices for Administrators

1. Design from the business first. Map jobs, departments, and access needs before building roles and policies.

2. Prefer roles over individual assignments. This keeps access scalable and easier to certify.

3. Keep policies readable. Use clear names and descriptions, and avoid unnecessary complexity.

4. Test changes safely. Use a test environment and a small group of pilot users before broad rollout.

5. Introduce enforcement gradually. Begin with marking, review results, and then move to stronger actions where justified.

6. Plan orphan handling. Define who owns unmatched accounts, how adoption rules work, and how long exceptions may remain.

7. Schedule and partition reconciliation sensibly. Balance data freshness against load.

8. Monitor and alert. Track reconciliation failures, workflow backlogs, and noncompliant account counts.

9. Keep the HR feed clean. Wrong manager, department, or status data leads to wrong provisioning. Identity governance depends on reliable source data.

10. Review regularly. Combine policy reviews with access recertification so outdated entitlements are removed.

Part 6: Troubleshooting Scenarios

Scenario A: A user does not receive an account they should have

Checks:

1. Is the person actually a member of the role the policy uses?

2. Is the provisioning policy enabled, and not in draft state?

3. Is the entitlement automatic, or is it manual and waiting for a request?

4. Does the person’s data satisfy the policy conditions?

5. Did the provisioning request fail, or is it pending an approval?

6. Is the target adapter available?

Scenario B: A user receives an account with the wrong attribute value

Checks:

1. Which provisioning policy parameter sets the attribute?

2. Do several policies apply to the person, and how are their values combined?

3. Is the source person attribute (such as department) correct?

4. Was the account value changed on the target afterward?

5. What is the enforcement type for that parameter?

Scenario C: Reconciliation completes but the expected accounts are missing

Checks:

1. Is the reconciliation query or filter too narrow?

2. Does the service account used by the adapter have permission to read all the relevant accounts?

3. Is the search base or scope correct?

4. Are the accounts perhaps in a different container or domain?

Scenario D: Accounts are suspended unexpectedly after reconciliation

Checks:

1. What enforcement action is set on the service?

2. Which policy marked the accounts as noncompliant?

3. Was a policy recently changed, or a role membership removed?

4. Did a bad HR feed alter people’s attributes?

Reviewing what changed recently answers most of these quickly.

Part 7: Interview Questions on This Topic

Learners often face these questions in IBM ISIM interviews:

1. What is reconciliation in ISIM, and why is it needed?

2. What is an orphan account, and how do you handle it?

3. What is the difference between account reconciliation and supporting-data reconciliation?

4. What is a provisioning policy, and what are its main components?

5. What is the difference between automatic and manual entitlements?

6. How does ISIM behave when multiple provisioning policies apply to one user?

7. What enforcement options exist for noncompliant accounts?

8. How would you troubleshoot a reconciliation that fails or runs very slowly?

9. A new joiner did not receive access automatically. What do you check?

10. How do identity policies differ from provisioning policies?

Answer tip: Use a simple structure: define the concept, give a real example, describe a common problem, and explain how you would prevent it. Interviewers value clear reasoning more than memorized definitions.

Part 8: Reconciliation vs Provisioning Policies at a Glance

9. Why ProExcellency Is the No.1 

Here’s why ProExcellency Solutions is continuously in :

• Certified Trainers with 10+ years of experience

• one hundred % Practical-Oriented Learning

• Flexible Online & Weekend Batches

• Training Projects and Case Studies

• Affordable Fee Structure

• Placement & Resume Support

• High Success Rate in Certification Exam.

10. Frequently Asked Questions

Is reconciliation the same as provisioning?
No. Provisioning pushes accounts and changes from ISIM to target systems. Reconciliation reads accounts from target systems into ISIM.

How often should reconciliation run?
It depends on risk and size. Many organizations run it daily or weekly for important systems, and less often for low-risk ones. Balance freshness against system load.

Can reconciliation delete accounts?
Reconciliation itself reads data. Actions such as suspending or correcting accounts come from policy enforcement settings after the comparison, so configure them carefully.

What happens to orphan accounts?
They can be adopted by an owner, suspended, deleted, or documented as exceptions, according to your governance process.

Do I need roles to use provisioning policies?
Not strictly, but roles are the best practice for membership because they scale and are easier to audit.

Is IBM ISIM still worth learning?
 Many enterprises still run ISIM or are moving to IBM Security Verify Governance. The concepts of reconciliation, policies, workflows, and access certification carry over to other identity governance tools too.

Final Thoughts

Reconciliation and provisioning policies are the heart of IBM ISIM. Reconciliation shows the truth about what exists across your systems. Provisioning policies describe what the business wants. When the two are designed well and kept in sync, new employees get the right access quickly, movers lose what they no longer need, leavers are cut off reliably, and audits become routine instead of stressful.

For learners, mastering these two topics gives you a strong base for everything else in ISIM, from workflows and adapters to access recertification and troubleshooting. Practice them in a lab: create a service, run a reconciliation, find orphans, build a role-based provisioning policy, and watch what ISIM does when you change a person’s role. Real hands-on experience turns definitions into confidence, and confidence is what employers look for in identity and access management professionals.