CIS account and credential policy template (Controls 5 and 6)

What a CIS account and credential management policy template must set

A team that must document its account and credential rules for a customer, contract or regulator can start with the free CIS policy template for Controls 5 and 6. The template is built for IG1 Safeguards only, so it does not address IG2 or IG3 Safeguards. Whatever the template is adapted into, the written policy has to state rules for five areas: the account inventory, unique passwords, dormant accounts, access granting and revoking, and multi-factor authentication (MFA) for internet-facing and administrative access. The policy should set the inventory scope first. Safeguard 5.1 expects every account the enterprise manages, including user, administrator and service accounts, with at least the person's name, username, start and stop dates and department recorded. The policy must name the owner of that inventory and the quarterly validation of active accounts, and it should say what happens when an account cannot be matched to an authorized person. Other rules to write down are the unique password minimums CIS gives as best practice (8 characters where MFA is used, 14 where it is not), the 45-day dormant account rule in Safeguard 5.3 and the processes for granting access in Safeguard 6.1 and revoking it in Safeguard 6.2. Confirm with your own identity team how each rule will be enforced in your directory, since the policy must describe what the organization actually does. The organization owns the policy and the controls. An implementation partner can configure identity systems, produce inventory exports and collect the logs that show validation and disabling happened. Only an independent auditor or assessor can issue a report or opinion on the result. Ask any partner to confirm in writing which artifacts it will deliver and which decisions remain with your security and HR owners.

How the account inventory and quarterly validation get scored

Safeguard 5.1 asks for one inventory that covers every account the enterprise manages, with a named owner and a quarterly check that active accounts are still authorized. The cards below cover where the inventory data comes from, who validates it, what evidence proves the check happened and the gaps that most often cause a finding.

Inventory sources to reconcile

No single system holds every account. Pull from directory services, SaaS admin consoles, cloud identity providers, local accounts on servers and network devices, and privileged access tools. Reconcile these sources against each other before the first validation, because an inventory built from one directory will miss local and application accounts. Ask which systems were excluded and why, and record that decision in the policy.

Required fields for each account

Safeguard 5.1 lists the person's name, username, start and stop dates and department. Each record needs all five fields populated for user, administrator and service accounts alike. For service accounts, the named owner can stand in for the person's name, but the owner must be recorded. Blank start dates and missing departments are the fields assessors check first.

Validation owner and authority

Assign one accountable owner for the quarterly validation, usually the identity or access manager, with managers of each department confirming their own staff's accounts. The owner needs authority to disable accounts that are not confirmed. Record the owner's name and role in the policy so an assessor can trace who signed off each cycle.

Dated exports and sign-off records

The evidence is a dated export of the inventory taken at the start of each quarterly window, a record of each account marked as authorized or removed, and the approver's signature or ticket reference. Keep the exports in an append-only location so earlier cycles cannot be altered. Ask the auditor which format and retention period they will accept before the first cycle.

Service accounts missing from the list

Service accounts used by scheduled jobs, integrations, backup agents and application-to-application connections are the most common gap. They rarely have a human owner, so they drop out of directory-based exports. Scan for them in configuration files, scheduled task lists and secrets vaults, then assign an owner to each one before the validation starts.

Quarterly window and stale entries

The validation runs at least once per quarter, and the scoring checks that active accounts were confirmed as authorized within that window. Entries marked for removal that remain active after the window closes count as open findings. Track the date each account was last confirmed, so a late confirmation shows up before the auditor finds it.

How access granting and revoking processes are tested

The granting and revoking processes form one lifecycle that starts when a person joins or changes role and ends when access is removed. An assessor checks that each phase is written down, automated where practical, and actually followed, with records that show it happened.

Document the access granting process
The organization writes down how a new hire or a person changing role receives access to enterprise assets. Safeguard 6.1 asks for a process that the enterprise actually follows, and ideally automates, so the written steps should name who requests access, who approves it, which systems are provisioned, and where the record lives. Access is granted from that process, not from ad hoc requests. The output is an approved procedure and a sample of tickets or workflow records that show it in use.
Trigger access from the hiring or role change event
The granting process starts from a known event, usually an HR record that shows a start date or a transfer to a new department or role. Connecting provisioning to the HR system or identity directory reduces the chance that access is requested late or never. An assessor will ask how the organization learns that someone has joined or moved, so the trigger and its source system should be documented. The output is a provisioning request linked to the personnel change.
Approve and provision access to enterprise assets
A manager or data owner approves the access that matches the new role, and an administrator or automated workflow creates the accounts and permissions. Approvals should be recorded with the approver's name and date, and the granted access should match the approved request. Assessors compare the approval record with the account that was actually created, so mismatches are a common finding. The output is an approved request and a provisioned account with matching entitlements.
Trigger revocation when a user leaves or changes role
The revoking process starts from the same kind of event in reverse: a departure, a loss of rights or a role change. Safeguard 6.2 asks for a process, ideally automated, that disables access as soon as one of these events occurs. The trigger should come from the HR record or a termination ticket, and the owner of the process should be named. The output is a revocation request dated to the event that caused it.
Disable accounts rather than delete them
When access is removed, the account is normally disabled instead of deleted. Disabling keeps the account's history, group memberships and logs intact, which supports investigations, audit trails and the reconstruction of past activity. Deletion can break references in logs and records. Organizations should confirm with their auditor how long disabled accounts are kept and where the disable action is recorded. The output is a disabled account with its prior entitlements and history preserved.
Remove access from every connected system
Removing access must reach each system that holds the person's credentials, including cloud applications, on-premises systems, shared accounts the person knew and any service provider platforms. Gaps often appear in systems that are not connected to the central directory. The organization should keep a list of systems that revocation covers and check it against the account inventory from Safeguard 5.1. The output is a checklist or automated report confirming that each system was cleared.
Retain evidence that the process was followed
Assessors test whether the process operates, so the organization must keep records from each cycle: approvals, provisioning logs, revocation tickets, disable timestamps and the list of systems cleared. A sample of joiners, movers and leavers is typically selected to check that records exist and match the written process. Organizations should confirm with their assessor which samples and periods are expected. The output is a set of retained records that show the lifecycle ran as written.

Where MFA is required and how central enforcement counts

Safeguard 6.3 asks for multi-factor authentication on every application that faces the internet, whether the enterprise built it or a third party runs it. The test is scoped to exposure: if users or outsiders can reach the login page from outside the network, the application is in scope. The Safeguard applies where the application supports MFA, so the work starts with an inventory of external-facing applications and a check of each one's authentication options.

Own and third-party apps: Count vendor-hosted SaaS tools, customer portals and partner access points, not only applications your teams deployed.
Support check: Record for each application whether it offers MFA natively, through a federated identity provider or not at all.
Scope of users: Confirm that MFA covers all user types who log in, including contractors and service desk staff, not only employees.
Unsupported applications: Log each application that cannot support MFA, with the compensating control, the owner and a review date.
Evidence: Keep configuration exports or screenshots showing MFA enforced for each application on the list.

Before you rely on this Safeguard, confirm with your assessor how they will sample applications and what they accept as proof of an enforced setting.

What must be in place before an assessor reviews the policy

An assessor testing Safeguards 5.1 through 6.5 looks for records that prove the policy runs, not just that it exists. The cards below are checks a team can run on its own before any outside review, and they connect through one question: can the organization show who holds each account, why, and whether that access still holds up.

Account inventory tied to the identity provider

Build one inventory covering user, administrator and service accounts, recording at least name, username, start and stop dates and department, as Safeguard 5.1 asks. Reconcile it against the directory or identity provider export so every active account appears in both places. Accounts that exist in a system but not in the inventory are the first gap an assessor finds. Confirm that the export and the inventory match before the review starts.

Written policy with named owners

The policy needs an accountable owner for the account inventory, for access grants and revocations, and for exceptions. Each role should name a person or team, not a generic function. Record the approval date and the review cycle the policy sets, so an assessor can see that the document is current and that someone is responsible for keeping it that way. Confirm that the owners know what they are expected to produce.

Records of quarterly account reviews

Keep dated records showing that someone validated each active account as authorized at least once per quarter. The record should show who reviewed, which accounts were confirmed, which were disabled and why. A review that exists only as a verbal confirmation or an unsigned spreadsheet is hard to defend. Keep the evidence for each quarter in the same location so that the sequence is visible.

Dormant account reports

Run a report of accounts with no sign-in activity beyond the 45-day threshold in Safeguard 5.3, then show the action taken for each one: disabled, deleted or documented as a justified exception. Test the report against a known dormant test account so you know it captures what it should. Where a system does not expose last-login data, record that limitation and the manual process used instead.

Application and admin asset MFA status list

List every internet-facing application, whether built in-house or provided by a third party, and every asset with administrative access. For each, record whether MFA is enforced, where it is enforced (application or central identity provider) and whether the asset supports it. Safeguard 6.5 extends the requirement to administrative accounts managed by a service provider, so include those too. Gaps in this list drive the exceptions process below.

Documented exceptions process

Some systems cannot enforce MFA or unique passwords. Record each one with its technical reason, the compensating controls in use, an owner, an approval by a named manager, and a review date. Exceptions with no expiry or owner are the most common finding in account reviews. Confirm with each system vendor whether the limitation can be removed in a later release, and track that answer alongside the exception.

Who owns the policy, the controls and the evidence

This table compares the three parties involved in a CIS account and credential program: the organization, an implementation partner and the independent assessor. Read each row as a question of who does the work, who approves it and who can issue a report. The main takeaway is that the policy and the accounts remain the organization's responsibility, and only an independent assessor can issue an assessment report.

Responsibility	The organization	Implementation partner (for example DeployOpen)	Independent auditor or assessor
Account and credential policy	Owns and approves the written policy, sets password length rules and dormant account handling	Drafts configuration aligned to the approved policy if asked, flags gaps between policy and systems	Reads the policy and checks that it matches what the organization actually does
Account inventory (Safeguard 5.1)	Owns the inventory and confirms each active account is authorized at least quarterly	Builds directory reports and scheduled exports that list accounts with the required fields	Samples the inventory and compares it with directory and system records
Exceptions and risk acceptance	Approves every exception to password, dormant account or MFA rules in writing	Documents exception requests and tracks their expiry in the client's ticketing system	Tests whether exceptions were approved, recorded and reviewed
Access granting and revoking (Safeguards 6.1 and 6.2)	Runs the hiring, role change and leaver processes and approves access requests	Automates joiner, mover and leaver workflows in the client's identity platform	Traces sample joiners and leavers through tickets and system logs
MFA for exposed and admin access (Safeguards 6.3 and 6.5)	Decides which applications and admin accounts are in scope and accepts any MFA exceptions	Configures MFA enforcement in the directory or SSO platform and collects enrollment reports	Checks enforcement settings and tests a sample of internet-facing applications
Evidence collection	Keeps evidence and makes it available to the assessor on request	Sets up repeatable evidence exports and retention in the client's environment	Decides which evidence is sufficient and tests its integrity
Report or certificate	Receives the assessment result and decides on remediation	Does not issue reports, attestations or certificates	Only party that issues an assessment report or certification, where the scheme provides one

Questions teams ask before writing this policy

Is IG1 enough for an account and credential policy?

IG1 is enough for many organizations as a starting point, because CIS defines it as essential cyber hygiene and a minimum standard for every enterprise. The CIS policy templates were written only for IG1 Safeguards, so they cover Safeguards 5.1, 5.2, 5.3, 6.1, 6.2, 6.3 and 6.5 at that level. Whether IG1 is sufficient for your organization depends on your data sensitivity, regulatory duties and threat exposure. If a customer, regulator or contract asks for IG2 or IG3 Safeguards, the template will not cover them, so you will need additional procedures. Confirm your target Implementation Group with the party requiring it before you start.

What do the CIS policy templates cost to use?

CIS says the Controls are free for any organization to use to improve its own cybersecurity, and its content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0. Commercial use requires CIS's prior approval, so check the terms before you reuse the template in a product, a paid service or a commercial offering. Your real cost is the internal and external effort to adapt the template, approve it, run the account reviews and collect evidence. Ask any consultant to state in writing which parts of that effort they will do, and whether they need CIS approval for any commercial use they propose.

How long does it take to write and evidence this policy?

The duration depends mainly on the size and state of your directory and application estate, and on how many identity and application owners must review the document. A single directory with well-documented joiner and leaver processes will take less time than many separate applications with local accounts. Confirm the timeline internally with your identity team, and ask any implementation partner to base its schedule on a written scope that lists the directories, applications and service accounts in play. Evidence collection continues after the policy is approved, because the quarterly account validation and dormant account checks must run and be recorded.

Can our own team write this policy without outside help?

Yes, an internal team can adapt the CIS template, provided it has the authority to define access rules and the time to test them. The template needs local decisions, such as your account naming, the owners of each system, your joiner and leaver workflow and how you handle service accounts. Teams often struggle with proving that processes are followed, not just documented, which is the core of the assessment specification's checks. Outside help is usually considered when the estate is large, when integrations are complex or when an independent assessor will review the evidence later. Any external partner prepares systems and evidence, while only an independent auditor or assessor issues a report.

What do identity and application owners need to contribute?

Identity owners must provide the directory and SSO configuration, confirm which accounts exist, and show how MFA is enforced centrally. Application owners must confirm which internet-facing applications exist, whether each supports MFA, and who holds administrative access to each enterprise asset. Both groups must also agree on the quarterly account validation, the 45-day dormant account rule and the timing of access removal when someone leaves. Ask for named owners in writing before the project starts, because most delays come from unclear responsibility for legacy applications and service accounts.

Do CIS policy templates map to other frameworks?

CIS states that it maintains mappings to frameworks such as the NIST Cybersecurity Framework, NIST SP 800-53, the ISO 27000 series, PCI DSS, HIPAA and NERC CIP. As of October 2026, the CIS Controls Navigator for v8.1 offers mappings to 30 frameworks and versions, including ISO/IEC 27001:2022, SOC 2, PCI DSS v4.0, DORA and NIS2. CIS also says the Controls do not replace any regulatory, compliance or authorization scheme, so a mapping shows overlap, not equivalence. Use the Navigator to check the specific mapping you need, and confirm with your assessor or regulator how they will treat the evidence before you rely on it.

Why account policy projects stall and how to avoid it

Account policy projects rarely stall on the policy text. They stall when the inventory that Safeguard 5.1 requires turns out to be incomplete, because applications outside the identity provider, service accounts with shared passwords and HR records that never reach the directory mean the organization cannot show who holds access. Shadow applications that sign users in with local credentials fall outside Safeguard 6.3, which asks for multi-factor authentication on internet-facing applications where the application supports it, so each one becomes a remediation item found late in the project. Start by reconciling the directory against the finance, SaaS and cloud admin consoles, and treat every application that cannot federate to single sign-on as a named exception with an owner and a decision date.

Dormant account rules cause the second common delay. Safeguard 5.3 asks for inactive accounts to be deleted or disabled after 45 days where the system supports it, and many legacy systems, appliances and service accounts have no native disable function. Agree in writing which systems are excluded because they cannot support the action, what compensating control applies to each (for example, restricting the account to a named host or rotating its credential), and who signs off on each exception. Confirm with each system owner whether disabling breaks a scheduled job before the rule is switched on, since an outage in the first week will undermine the whole program.

HR data is the third delay. Safeguards 6.1 and 6.2 depend on joiner, mover and leaver events reaching the identity system promptly, and if the HR system of record is not connected, access is granted and removed by ticket, which is slow and easy to miss. Ask your HR and identity owners to confirm which events are automated today and which are manual, and agree the scope of the first phase in a written statement of work before any configuration begins. That document should name the systems in scope, the exceptions and their approvers, the evidence each Safeguard will produce, and who owns the output. Fixed scope agreed up front is the most reliable way to keep an account project from drifting.

How DeployOpen prepares account and credential evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the account and credential controls that the CIS policy template describes can be configured and evidenced where your accounts actually live. We prepare the systems and records; your organization owns the policy, the decisions and the controls, and an independent assessor or auditor reaches any conclusion about them.

How we scope

Engagements are fixed-scope, with the account systems, directories and applications in scope agreed in writing before work starts.
The written scope names which Safeguards 5.1 to 5.3 and 6.1 to 6.5 apply to each system, so gaps are visible up front.
Scope also records who owns the account inventory, the quarterly validation step and the access granting and revoking approvals.

How we build

We configure the account inventory so it records name, username, start and stop dates and department for every managed account.
We set up dormant account handling aimed at the 45-day inactivity rule, where the platform supports it, and document any gaps.
We enforce MFA for internet-facing applications and administrative access through the directory or SSO layer where the platform allows it.

How we hand over

You receive the configuration records, account inventory exports and access process documentation mapped to each Safeguard in scope.
Test evidence shows how each control was checked, such as sample dormant account results and MFA enforcement settings.
Handover includes a list of open items you must confirm with your own teams or with the platform vendor before an assessment.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover quarterly account review evidence so the inventory stays current between assessments.
Any assessment, certification or attestation is issued only by the independent auditor or assessor you select, not by DeployOpen.

CIS account and credential management policy template (Controls 5 and 6)