CIP-004-7 R5 Access revocation: requirements and evidence

What CIP-004-7 R5 access revocation requires when staff leave or move

CIP-004-7 R5 requires a registered entity to take away access on fixed clocks when someone leaves or changes role, and the clocks differ by event. For a termination, unescorted physical access and Interactive Remote Access must be removed within 24 hours of the termination action. For a reassignment or transfer, access that is no longer needed must be revoked by the end of the next calendar day after the entity determines it is not needed. The 24-hour and next-day clocks protect against a former employee or a reassigned contractor keeping a route into a BES Cyber System while the organization assumes the account is already gone. Confirm with your Regional Entity which of your systems and access paths fall under these parts before you set internal deadlines, because scope depends on your impact rating from CIP-002.

Two further obligations address accounts that outlive the person. For high impact BES Cyber Systems and their associated EACMS, non-shared user accounts must be revoked within 30 calendar days of a termination action. Shared account passwords that the departing or moving person knew must be changed within 30 calendar days of a termination, reassignment or transfer. The 30-day window covers accounts that sit outside the fast removal path, such as local accounts on devices. The standard allows a longer shared-password period only when extenuating operating circumstances are determined and documented, and then the change must happen within 10 calendar days after those circumstances end. Auditors will ask for the documented determination, so treat it as a formal record, not a verbal decision.

The work is hard because one person often holds access in many places that do not share a record. Access may be granted in a corporate directory, in application-level roles, in a physical badge system, in VPN or remote access tools, and in local accounts on field devices. Shared accounts make it harder still, since no single record ties a password to a person. Contractors and staff moving between control rooms add a second problem: the transfer event may reach HR systems days after the operational need ended. A practical first step is to map every access path for each BES Cyber System, identify which ones are fed by a central identity source, and time-stamp each termination or transfer event from the moment the entity makes the determination.

Which systems and people CIP-004-7 R5 access revocation covers

Revocation work is only as complete as the inventory behind it. The scope decisions below determine which accounts, systems, physical access paths and stores must be included when a person leaves or changes role. Confirm each driver against the Applicable Systems column of CIP-004-7 and your own CIP-002 categorization before you size the program.

High impact BES Cyber Systems and EACMS

The 30-day window for removing non-shared user accounts and changing shared passwords applies to high impact BES Cyber Systems and their associated EACMS. Build a separate account inventory for these assets so the 30-day clock can be shown for each one. Confirm with the standard table whether a given asset falls inside this subset, because the scope for these parts is narrower than for Parts 5.1 and 5.2.

Applicable Systems for Parts 5.1 and 5.2

Parts 5.1 and 5.2 apply by the Applicable Systems column, which is broader than the high impact subset. Termination removal and next-day transfer revocation must cover every in-scope system the standard table names for those parts. Ask your compliance lead to map each Applicable System to the access paths that reach it, so no system is missed in the revocation checklist.

PACS and unescorted physical access

Unescorted physical access is revoked under the termination requirement, so the people who hold badges to Physical Access Control Systems belong in the same workflow as network accounts. Removing a logical account does not remove a badge or a cardholder record in the PACS. Confirm that badge deactivation and PACS record removal are tracked against the same termination action and timestamp.

Contractors and vendor staff

Contractors, integrators and vendor technicians often hold Interactive Remote Access or local accounts that are not issued by your HR system. Their end dates come from contract or statement-of-work changes, which can arrive late. Maintain a registry of non-employee access with contract end dates, sponsor names and the systems each person can reach, and treat a contract end as a termination action for revocation purposes.

Shared accounts and their known users

Shared password changes under Part 5.4 depend on knowing who had the password. Identify every shared account on in-scope high impact systems and record the individuals who know its credentials. An undocumented shared account can leave a departed person with access that no revocation step touches. Confirm with your standard interpretation how you will document the known-user list.

BES Cyber System Information stores

Access to BES Cyber System Information is governed by CIP-004-7 R6, and revocation must reach every location where that information is held, including cloud and third-party repositories. Wiki pages, ticket attachments, backup copies and shared drives can all hold BCSI. Inventory these stores alongside the system inventory, and confirm that departing users lose access to each one, not only to the production system.

How the 24-hour, next-day and 30-day clocks work in practice

The clock that auditors check first is the one that starts the moment the entity records a triggering event, so the timestamp of that event matters as much as the removal itself. For a termination action under Part 5.1, the 24-hour period covers both initiating removal of unescorted physical access and Interactive Remote Access and completing those removals. For a reassignment or transfer under Part 5.2, the clock does not start at the personnel change. It starts when the entity determines that access is no longer needed, and removal is due by the end of the next calendar day after that determination. The gap between a manager's notice and the formal determination is where most evidence problems begin, so define in your procedure who makes that determination, how it is recorded and where the record lives. Confirm with your Compliance Enforcement Authority how they expect the start time to be documented before you rely on it.

Parts 5.3 and 5.4 use a 30-calendar-day window for different objects. Part 5.3 covers non-shared user accounts for high impact BES Cyber Systems and their associated EACMS, measured from the termination action. Part 5.4 covers passwords for shared accounts known to the user and runs from the termination, reassignment or transfer. Because these windows run from different triggers, a single HR feed will not give you all the start dates. Your ticketing or identity records need to show the event type and the timestamp for each affected account, so an auditor can reconstruct every clock without interviews.

Part 5.4 also allows a longer period for shared password changes when extenuating operating circumstances require it. The entity must determine that the circumstances exist and document that determination. Once the circumstances end, the passwords must be changed within 10 calendar days. Treat this as an exception with its own record: capture who made the determination, when the circumstances began, and the date they ended, and set a reminder to close the exception. Illustrative example: a shared operator account is kept in place during a storm response, and the change is due 10 calendar days after the response is declared over. Confirm the exact documentation expected for this allowance with your auditor, since they will test whether the determination was made and recorded before the standard period expired.

How an auditor tests CIP-004-7 R5 access revocation

The table lists the steps an auditor typically takes to test access revocation, what each step samples, the evidence requested and the findings that most often follow. Read it as a checklist of what your records must prove before the audit starts. The Compliance Enforcement Authority chooses the sample and the audit period, so every termination and transfer in the period can be selected.

Test step	What the auditor samples	Evidence requested	Common findings
Select terminations and transfers	Termination and reassignment or transfer actions in the audit period, drawn by the Compliance Enforcement Authority	HR or identity system records showing the action, its date and time, and the person affected	Triggers missing from HR or ticketing records, so the start of the clock cannot be shown
Compare trigger to removal timestamps	Each sampled termination, matched to the time its access was removed from physical and Interactive Remote Access paths	Timestamped logs from badge systems, VPN or Intermediate System, directory and access management tools	Removals completed after 24 hours, with no record of when the process started
Check the next-day transfer deadline	Each sampled transfer, checking whether unneeded access was revoked by the end of the next calendar day after the need ended	Access change tickets, approval records and revocation logs dated against the determination	Determination date unclear, so the auditor cannot tell when the next-day period began
Check non-shared account revocation for high impact systems	Non-shared user accounts of terminated personnel on high impact BES Cyber Systems and their EACMS, within 30 calendar days	Account disable or deletion records, and a list of accounts tied to each person	Accounts left active in local, vendor or emergency accounts that were never tied to the directory
Check shared password changes for high impact systems	Shared accounts the departing or transferring person knew, with password change records within 30 calendar days	Password change logs or vault records, and the list of shared accounts with known users	Shared account inventory outdated, so some accounts were never reviewed
Review extenuating circumstance documentation	Any shared password change that ran beyond 30 days, checking the documented determination and the change within 10 days after the circumstance ended	Written determination with reasons, approval record and the later change record	Determination written after the fact, or no end date set for the circumstance
Review the documented removal process	The written process that starts removals on a termination action and the steps taken to complete them	Current process document, revision history and evidence it was followed for sampled cases	Process does not name who starts removal or how the clock is recorded
Confirm removals reached every system with access	Each sampled individual's access across PACS, Interactive Remote Access, cloud services and single sign-on connected applications	Access reports from each system, showing the account is disabled or removed after the action	Access removed from the directory but still active in a PACS, cloud tenant or SSO-connected application

Implementing CIP-004-7 R5 access revocation in order

This sequence turns CIP-004-7 R5 from a policy statement into a working removal process, with an inventory of every place access lives, triggers tied to HR and access workflows, and evidence that shows each removal was completed on time. The organization owns the process and its timers; an implementation partner can help prepare the systems and records that support it.

Inventory every grant of access
List each place where access to in-scope BES Cyber Systems, their associated EACMS and PACS, and BES Cyber System Information is granted. Typical entries include the corporate directory, application accounts, PACS badge systems, remote access systems, local accounts on Cyber Assets and shared accounts. Record the owner of each store and whether the access is electronic, unescorted physical, Interactive Remote Access or BCSI access. The step is done when every access path maps to a named owner and a system of record, and no path is recorded as unknown.
Define termination and transfer triggers
Agree with HR and the access request owners which events start removal. A termination action and a reassignment or transfer need different triggers, because the R5 Part 5.1 and Part 5.2 clocks start from different points. Document the source feeds, such as HR status changes, contractor end dates and role change tickets, and the person who confirms each trigger. The output is a trigger matrix that states which event starts which removal process and who is accountable for acting on it.
Write the removal process with owners and timers
Write the procedure that runs after each trigger. It should name the owner for each removal action, the sequence for physical and remote access, the point at which a removal is considered determined needed or not needed, and how each step is logged. Map the 24-hour termination removal under Part 5.1 and the end-of-next-calendar-day revocation under Part 5.2 to specific tasks and escalation contacts. The output is an approved procedure that a new administrator could follow without asking for context.
Automate deprovisioning where feasible
Where a directory or identity platform is the source of truth, connect it to the target applications so that a change in the source removes or disables the account downstream. Open-source options such as authentik, which pushes user changes and deletions to target applications over SCIM 2.0, can support this for applications that accept provisioning. Manual steps remain for systems without an integration, such as some PACS and Cyber Assets. The output is a list of automated and manual removal paths, with test results for each automated path.
Build the shared account password change procedure
For high impact BES Cyber Systems and their associated EACMS, document how shared accounts known to a departing or transferred person are identified and how their passwords are changed within the 30-calendar-day window in Part 5.4. Include the path for extenuating operating circumstances, which must be determined and documented, with password changes due within 10 calendar days after those circumstances end. The output is a shared account register, a password change runbook and a written extenuating circumstances template with an approver.
Set up evidence capture and recurring testing
Configure logging so each removal records the trigger date, the action taken, the actor, and the completion timestamp, and keep the change records from the directory, PACS and remote access systems. Schedule a recurring test that picks sample terminations and transfers, traces them through the logs and confirms the removals met the required periods. Record the test results and any exceptions with owners. The step is complete when an auditor could follow one sampled removal from trigger to closure using the stored records.

Evidence that passes a CIP-004-7 R5 review

An auditor testing CIP-004-7 R5 will trace a sample of departures and role changes from the trigger to the moment access actually stopped. The cards below cover the artifacts that let that trace hold together, from the written process through each system that grants access. The organization owns this evidence, and the auditor decides whether it is sufficient.

Written removal process

This is the documented procedure that names each trigger, such as a termination action or a reassignment, and the owner responsible for starting each removal. Check that it separates the 24-hour termination path from the next-calendar-day transfer path and assigns an owner to the 30-day account and password steps. Review it at least annually and keep prior versions so an auditor can see what applied on the date of a sampled event. Confirm the process with your compliance team before relying on it.

HR and identity event records

Termination and transfer timestamps from HR systems or the identity provider establish the start of every removal clock. Export these events with the actor, effective date and time zone, and keep them tied to the ticket or workflow that triggered each removal. Gaps between an HR effective date and the system entry are the first thing a reviewer will question, so confirm how late-entered HR actions are recorded. Store exports on a schedule your team can prove.

Directory and application deprovisioning logs

Logs from the directory, single sign-on and target applications show when each account was disabled or deleted. Where a SCIM or LDAP connector performs the removal, capture both the trigger and the completion event so the interval is visible. Confirm how often your sync runs, since a scheduled sync can add delay that the process must account for. Restrict who can alter or purge these logs, and keep them for the period your retention policy requires.

PACS badge deactivation records

Physical access control system logs show when a badge or credential was deactivated at each Physical Security Perimeter door. Pair these records with the HR termination entry for unescorted access, which is the physical half of the 24-hour requirement. Include the badge holder, the operator who made the change, and the deactivation time, and confirm that PACS time synchronization matches the identity systems. Reconcile PACS roster counts against the authorization list at regular intervals.

Shared account password change records

For high impact BES Cyber Systems and their associated EACMS, shared account passwords known to a departing or transferring person must change within 30 calendar days. Keep a dated list of each affected shared account, the people who knew the credential, the change timestamp and the operator who made it. Vault or password manager audit trails often provide this, so confirm they record changes and not only retrieval. Reconcile the list against the shared account inventory.

Extenuating circumstance determinations

When operating conditions prevent a shared password change within 30 days, Part 5.4 allows a longer period only if the entity determines and documents the extenuating circumstances. Each determination should state the circumstance, the approver, the date the extension began and the end date, after which the password change is due within 10 calendar days. Track each open determination on a register so none expires unnoticed. Ask your Regional Entity contact early if you are unsure whether a circumstance qualifies.

What meeting CIP-004-7 R5 costs in money and effort

This table compares the main cost components of meeting CIP-004-7 R5 access revocation, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No supplied figure exists for these costs, so use the table to shape a written quote request rather than as a budget.

Cost component	One-time or recurring	What drives it up	How to keep it down
Identity and access tooling or licenses	Recurring license or subscription where commercial, plus one-time selection and deployment	Number of target systems, commercial license tiers, and the need for vendor support contracts	Self-hosted open-source identity platforms can remove license spend but add hosting, patching and operations work; confirm each platform's license terms and edition limits
Engineering time to integrate deprovisioning with each system	One-time for initial connectors, recurring when systems change	Number of Applicable Systems, legacy applications without SCIM or API support, and custom glue code	Prioritize systems holding high impact BES Cyber Systems and EACMS, and document which systems rely on manual steps
Process and procedure design	One-time, with periodic updates	Multiple termination and transfer paths, unclear ownership between HR, IT and operations, and weak triggers	Tie the 24-hour, next-day and 30-day clocks to a single HR-driven workflow with named owners
Shared account inventory and password change work	One-time inventory, recurring on personnel changes	Large numbers of shared accounts, undocumented service accounts, and devices with hard-coded credentials	Build and maintain a current inventory of shared accounts and the people who know their passwords before the first audit period
Evidence collection and retention	Recurring	Manual screenshots, disconnected ticketing systems, and logs kept in several places	Export timestamped records from the identity provider and ticketing system automatically, and store them under a single retention rule
Recurring access reviews and tests	Recurring	Frequency of reviews, size of the user population, and number of manual reconciliations	Automate reconciliation between HR records and directory accounts, and test sample terminations on a fixed schedule
External review or readiness support	Usually one-time readiness, optional recurring retainer	Scope of systems, gaps found in the first review, and the amount of remediation needed	Fix known gaps internally first, and agree the readiness scope in writing before work starts
Auditor sampling effort	Recurring with each Compliance Audit or Spot Check	Number of terminations in the audit period, missing timestamps, and unclear proof of completion	Keep one complete record per termination that shows the trigger time, each removal and the completion time

Which open-source identity tools support CIP-004-7 R5

CIP-004-7 R5 is met by the entity's own process and records, not by any single product. The tools below can help produce the timing evidence for removals, the account disablement history and the central authorization record. Each one needs to be checked against how your environment actually grants access.

authentik SCIM provisioning

The SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0. It runs a full sync every hour and deprovisions users from the target when they lose access to the application. For R5, this can show when a removal reached each connected system, but the sync interval means removals are not instant, so confirm that the hourly cycle fits inside your 24-hour and 30-day windows. Applications that do not support SCIM still need a documented manual removal path. License: MIT.

FreeIPA as the directory

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. It offers centralized access control and delegated administration through its web UI and command line tools. Use it as the authoritative source of identity so that a disabled account is disabled once, at the source. Confirm how delegated administrators are recorded, since those records will be part of your evidence. License: GPL-3.0-or-later.

Keycloak single sign-on

Keycloak provides single sign-on, so applications rely on one login point rather than each keeping its own credentials. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing OpenID Connect or SAML 2.0 identity providers. Disabling a user in Keycloak cuts off every application that trusts it, which makes it a strong control point for interactive access. Still confirm that direct or local accounts on devices and non-SSO systems are covered. License: Apache-2.0.

Zitadel as a central broker

Zitadel acts as a central identity broker, so users can sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP. Applications trust Zitadel instead of each provider. The risk to check is the split of authority: if a user is removed at the external provider but still active in Zitadel, or the reverse, your revocation timing is unclear. Document which system is the source of truth for each population. License: AGPL-3.0-only, which carries source-availability obligations if you modify and offer the software over a network, so have counsel review it.

Who owns CIP-004-7 R5 access revocation: your team, a partner and the auditor

Your organization remains the registered entity, so it owns the obligation, the decisions and the evidence. No partner or auditor can accept responsibility for whether a terminated employee lost physical and Interactive Remote Access within 24 hours. Your team must decide who initiates removal, which events count as termination, transfer or reassignment, and who is accountable when a step slips. These decisions belong in your own documented process and cannot be delegated away.

Trigger definition: Set the events that start removal, including terminations, reassignments, transfers and contractor offboarding, and tie each to a named initiating role.
Accountable roles: Name the owner of the CIP-004-7 access process, the owners of each access system and the approver of any exception.
Shared password decisions: Decide which shared accounts the user knew, document any extenuating operating circumstances that justify a longer window, and record when those circumstances end.
Evidence ownership: Keep the timestamps, tickets and approvals that show when removal was initiated and completed, and retain them for the audit period.
Internal testing: Sample terminated and transferred individuals regularly so you find gaps before a Regional Entity does.

Before engaging any partner, confirm that your own owner, triggers and evidence routine already exist in writing.

Where organizations miss CIP-004-7 R5 and how to close the gap

Most CIP-004-7 R5 findings do not come from missing policy. They come from slow triggers, untracked accounts and access paths that sit outside the directory. Each card below names one gap, what it looks like in practice and the check that closes it.

Manual tickets with no timestamp

When removal depends on someone opening a ticket and a technician acting on it later, the entity cannot show that removals finished within 24 hours of the termination action. Require the ticket to carry the termination time, the actual removal time and the name of the person who completed each step. Ask an auditor-style question: can you produce, for one departed employee, the exact times the trigger fired and the last access was removed?

Late termination triggers from HR

The 24-hour clock starts at the termination action, not when IT notices it. If HR records are updated days later, or a contractor's end date lives only in a sponsor's email, the clock effectively starts late and the entity still owes removal within the window. Confirm which system is the authoritative source for termination dates, how fast it propagates to access systems, and whether the trigger can start without a manual step.

Contractor and vendor accounts outside the directory

Vendor staff with Interactive Remote Access or unescorted access often hold local or application accounts that never enter the corporate directory. Removing the employee in HR leaves these accounts untouched. Build a register of every non-employee identity tied to BES Cyber Systems and their associated access paths, and confirm each one is either federated from the directory or has its own documented revocation step.

Shared accounts with no inventory

Part 5.4 requires password changes for shared accounts known to the departing or transferring person within 30 calendar days. Teams often cannot answer which shared accounts exist, which people know their passwords, or when the last change happened. Keep an inventory that maps each shared account to the individuals who know its credential, and record each rotation with a date. If operating circumstances justify a longer period, document them and confirm the 10-day limit after they end.

Transfers with no next-day trigger

A reassignment is not a termination, so it often falls outside the HR offboarding flow. The person keeps access for the old role because nobody raised a change. Part 5.2 expects access no longer needed to be revoked by the end of the next calendar day after the entity determines it is not needed. Add a transfer event to the identity process, make the determination point explicit, and test it with a sample of recent role changes.

Cloud and SaaS access left after directory removal

Removing a user from the central directory does not always remove access in applications that keep their own user store or cache sessions. Use an identity provider with SCIM or equivalent deprovisioning to push deletions to target applications, then verify the result in each application. Confirm that tokens and sessions are invalidated, and plan for CIP-004-8 virtualization changes, which take effect 1 July 2028, so they appear on the change plan now.

Questions buyers ask about CIP-004-7 R5 access revocation

How much work and cost does CIP-004-7 R5 add to a NERC CIP program?

R5 adds recurring operational work more than a large one-time build, and the cost follows the number of systems, identity sources and personnel changes you handle. The main cost components are internal staff time for HR triggers, ticket workflows and evidence collection, plus any licensing or integration work for the systems that actually remove access. Costs rise with the number of BES Cyber Systems and their associated EACMS in scope, the number of identity stores, and how many shared accounts exist. They fall when identity is centralized and removals are automated. Ask any provider for a quote that separates one-time integration work from recurring evidence and review effort, and that names the systems covered. DeployOpen does not publish prices; a quote follows from a written scope.

Can an in-house team meet CIP-004-7 R5 without outside help?

Many registered entities meet R5 with internal staff, especially when their identity and access tools are already well run. The questions to answer honestly are whether HR notifies access administrators of terminations and transfers quickly enough for the 24-hour and next-calendar-day windows, whether someone owns the shared account inventory, and whether the team can produce dated evidence for each removal. If those answers are unclear, an outside partner can help design the workflow and build the evidence trail, but the entity remains responsible for its compliance program. Independent auditors, not implementation partners, assess the result.

How long does it take to put CIP-004-7 R5 revocation in place?

The duration depends on scope: how many systems hold access, how many identity sources feed them, whether removals are automated or manual, and how much of the shared account inventory must be reviewed. A single control room with a few directory-integrated applications is a different project from a multi-site fleet with local accounts on field devices. No general timeline applies. Ask for a written plan that lists the systems in scope, the integration steps for each, the testing of removals, and the evidence to be captured, then compare it against your own change calendar and any audit date you are working toward.

What does the entity need to provide for R5 to work?

R5 depends on people and records outside the security team. You need an HR trigger that reliably starts the termination or transfer process, named system owners who can confirm which accounts and systems a person used, and access to authentication and directory logs that show when access was removed. Document the owner of each trigger and each system, because an auditor will ask who initiated a removal and when it was completed. Expect to supply contractor and vendor offboarding notices as well, since those are often the weakest link in the chain.

Can shared passwords be changed later under the extenuating circumstances allowance?

Yes, R5 Part 5.4 allows a longer period for changing shared account passwords when extenuating operating circumstances require it, but only if the entity determines and documents that the circumstances exist. In that case, the passwords must be changed within 10 calendar days after those circumstances end. Record the date the circumstances began, the operational reason, who approved the deferral, the date they ended, and the date the passwords were changed. The allowance is not a general extension, so keep the documented justification narrow and time-bound. Confirm the exact wording and scope with your Regional Entity and your compliance counsel before relying on it.

Does an identity provider alone satisfy CIP-004-7 R5?

No. An identity provider such as a single sign-on server or directory can remove access centrally and reduce the number of places a person must be deprovisioned, but it does not by itself satisfy R5. The entity still needs a documented process that starts removal on a termination or reassignment, completes it within the required windows, covers non-shared accounts and shared account passwords, and keeps records. Tools like SCIM provisioning, directory groups or brokered logins generate logs that support that evidence, and the entity must still show the process, its ownership and the results. Systems that are not connected to the identity provider, including local accounts, must be handled separately.

What does DeployOpen provide for a NERC CIP audit on access revocation?

DeployOpen plans, implements, configures and documents self-hosted open-source identity and access systems inside your own infrastructure, and it can prepare the systems, workflows and evidence that R5 requires. That work can include configuring provisioning and deprovisioning, testing removals, and documenting the procedure. DeployOpen does not issue audit reports, attestations or compliance determinations, and it does not act as the Compliance Enforcement Authority. The entity owns its controls and its responsibility to demonstrate compliance to the Regional Entity or NERC. Ask any partner to state in writing which evidence it prepares, which records remain the entity's to produce, and how it will support you during an audit request.

How DeployOpen scopes and prepares CIP-004-7 R5 access revocation

DeployOpen plans, implements and documents the access revocation path for CIP-004-7 R5 inside the client's own infrastructure. The organization keeps ownership of its controls and its compliance decisions, while DeployOpen prepares the systems, workflows and evidence an independent auditor will review.

How we scope

Confirm which BES Cyber Systems and associated EACMS fall under the high impact revocation rules, from the entity's CIP-002 categorization.
Map every identity source, application and shared account that grants unescorted physical or Interactive Remote Access today.
Agree the written scope, deliverables and timelines with the client before any work starts, since engagements are fixed-scope.

How we build

Connect the HR termination and transfer triggers to the identity provider so removal starts from a recorded action, not a manual ticket.
Configure deprovisioning in the chosen open-source identity platform, such as SCIM-based removal into target applications, and test each path.
Set up tracking for the 24-hour, next-day, 30-day and shared password timers so the entity can show when each step was completed.

How we hand over

Document the revocation procedure, roles, exception handling and the documented extenuating circumstances path for shared passwords.
Deliver test records and sample evidence packages that show removal timestamps for termination, transfer and account cleanup cases.
Walk the client's compliance and operations staff through the runbooks so they can produce evidence without DeployOpen involved.

How we support

Ongoing support, upgrades and continuous testing of the revocation workflow are available as a retainer.
Re-test the workflow after identity platform upgrades, new applications or changes to the entity's CIP-002 categorization.
Confirm with the client's auditor which evidence format and retention period they expect, since DeployOpen does not issue audit reports.