IA.L2-3.5.6 Identifier handling: requirements and evidence

What IA.L2-3.5.6 identifier handling asks for and why unused accounts matter

A CUI system almost always holds accounts that nobody is actively using: a contractor whose project ended, an engineer who changed roles, a service login created for a pilot that was never retired. IA.L2-3.5.6 asks the organization to define a period of inactivity after which an identifier is disabled, and then to actually disable identifiers that exceed it. The requirement is about identifiers, so the disabling applies to the account name itself, not only to its password. In practice, the compliance lead's first job is to write down the inactivity period and then prove that the period is enforced on every system in the boundary.

The risk is simple. A dormant account still accepts a valid login, and if no one reviews it, no one notices when someone else starts using it. Dormant credentials are a common way for an adversary to move inside a network without triggering alerts that were tuned for active users. NIST SP 800-171A breaks the requirement into two assessment objectives: the organization must define a period of inactivity after which an identifier is disabled, and it must disable identifiers after that period. An assessor will look for both. A written policy without disabling evidence fails the second objective, and automated disabling without a defined period fails the first. Under 32 CFR 170.24, IA.L2-3.5.6 is worth 1 point, and because it is not on the exclusion list in 32 CFR 170.21, it can go on a plan of action and milestones if the score qualifies for Conditional Level 2 status.

The hard part is measurement. A last-login date is easy to find on one application and hard to find across a directory, a VPN concentrator, a code repository, a ticketing tool and a set of Linux hosts that each keep their own records. Before setting the period, confirm which systems record last use, which do not, and which accounts sit outside the central directory entirely. Phase II of CMMC is suspended, but Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, so an inaccurate score on this requirement still carries contract consequences. The DoW CIO About CMMC page is the place to confirm the current status of the program.

Which accounts and systems does the inactivity rule reach?

The inactivity requirement applies to every identifier that can authenticate to a system in the CUI environment, not only to employee logins. Each card below is a scope decision that changes the account list an assessor will request and the disabling rule your organization must apply to it.

System accounts on in-scope CUI systems

Operating system, database, backup and monitoring accounts on systems that store, process or transmit CUI are identifiers in the account inventory. Decide which of them are interactive and which only run services, then record the owner and purpose of each. An assessor will check whether the defined inactivity period is applied to system accounts as well as to people, so an unowned system account with no recent use is a finding waiting to happen. Confirm the list against your system security plan.

Shared service identifiers and non-human accounts

Process and service identifiers, such as scheduled jobs, API clients and integration accounts, count as identifiers under this requirement. The decision is whether a service account that is still needed but rarely logs in is exempt, or whether it must follow the same defined inactivity rule with a documented owner who can renew it. Shared accounts used by several people create an additional question: an identifier that no single person owns can stay active long after the team that used it has changed. Document the decision and the renewal process for each one.

Accounts fed from directories and SaaS tools

When users reach the CUI environment through a central directory or an identity provider, the account lifecycle in the source system determines whether an identifier goes idle. Decide whether the inactivity rule is enforced in the directory, in each connected application, or in both, and confirm that a disabled upstream account also disables its downstream copies. Provisioning and deprovisioning connectors are where stale copies usually survive, so the account list an assessor receives should be pulled from every system that holds a usable identifier.

Contractor and third-party accounts

Accounts held by subcontractors, managed service providers and vendor support staff often sit outside the employee lifecycle and are the least visible in the inventory. Decide who sponsors each external identifier, what period of inactivity applies to it, and who receives the disabling notice when the engagement ends. Contract terms should state these duties, and the list of external identifiers should be reviewed on a schedule you define. Confirm with your contracts team which third-party accounts reach CUI today.

Physical access device identifiers

SP 800-171A lists identifiers generated from physical access control devices as potential evidence for this requirement. Badge and keycard credentials that open rooms where CUI systems are located may be treated as identifiers that can become inactive. Decide whether these credentials fall inside the same inactivity rule, and who reconciles badge status against the personnel roster. Physical and logical records should be reviewed together so a dormant badge cannot be used to reach a workstation.

How an assessor tests the inactivity period and the disabling step

This table compares what an assessor checks for each step of IA.L2-3.5.6, what evidence they request, and where organizations most often fall short. Read it as two linked tests: a defined inactivity period must exist, and the mechanism must actually disable identifiers once that period passes.

Test step	What the assessor examines	Evidence requested	Common finding
Objective 1: defined inactivity period	Whether the organization has set a specific number of inactive days after which an identifier is disabled	Written identifier management procedure stating the period, approval record and version history	No written period, or only a vague statement such as disable stale accounts
Period implemented in configuration	Whether the period in the policy is enforced by the directory, identity provider or application	Configuration export or screenshot showing the inactivity setting, with date and administrator	Period exists only in a policy document with no configured mechanism behind it
Objective 2: disabling after the period	Whether identifiers past the defined period are actually disabled	Account list with last logon dates compared against the defined period, and resulting disabled status	Accounts past the period still enabled, including service and shared accounts
Testing of identifier management mechanisms	Whether the automated or manual process runs as described and produces consistent results	Scheduled job or sync logs, sample test accounts that were allowed to lapse, and change tickets	Manual disabling with no record of who disabled what and when
Comparison of system accounts to policy	Whether every account in the system account list follows the inactivity rule, with exceptions documented	Full system account list, exception register with owner and justification, and reviewer sign-off	Accounts missing from the list, or exceptions granted with no owner or expiry
Final determination	Whether both objectives are satisfied with evidence in final form, not drafts	Approved procedure, current configuration evidence and dated account review	Requirement not MET because evidence is a draft or only covers part of the account population

How to set the inactivity period and automate disabling

This sequence turns the inactivity rule for IA.L2-3.5.6 into a written policy value, a directory or identity provider setting that enforces it, and evidence an assessor can test. Each step ends with an artifact you file for the assessment.

Document the inactivity period and its owner
Start by writing the inactivity period into the access control policy or the system security plan, and name the role that owns it, usually the system owner with the security office approving changes. The value must be a defined number of days, not a general statement that inactive accounts are removed. Assessors check for a defined period, so the sentence must state it explicitly. The CMMC Assessment Guide uses a 45-day example policy for illustration only, so choose a value your own risk analysis supports and be ready to justify it. The output is the signed policy language and the approval record that you file with the system security plan.
Inventory systems that record last-use data
Build a list of every system that holds user or service accounts in scope, and for each one record whether it stores a last-login or last-activity timestamp, where that data lives, and whether it can be queried. Include directories, operating systems, applications, VPN and remote access gateways, and any local accounts on appliances. Mark each gap where the system keeps no usable last-use data or where accounts sit outside central management. The output is an inventory with a column for last-use data source and a gap register that names an owner and remediation path for each gap. This inventory also feeds the account lists that assessors commonly request under 3.5.6.
Configure the disabling mechanism
Configure the directory or identity provider to disable accounts once they exceed the defined inactivity period, and where a system cannot read central last-use data, add a documented manual or scripted process with a named operator. Where accounts are provisioned to downstream applications, confirm that disabling in the source also removes or disables the account in each target. In an open-source stack, FreeIPA with 389 Directory Server holds the user store and can be used as the authoritative directory, while authentik can push user and group changes to target applications over SCIM 2.0. Confirm each vendor's exact inactivity-handling feature in its documentation before relying on it. The output is a configuration export or screenshot set with the setting values, plus the change record that approves them.
Test a dummy account through the full cycle
Create a test account that is never used, let it cross the defined inactivity period in a non-production or controlled environment, and confirm that it is disabled in the directory and in every target application it reaches. Then verify that it cannot authenticate, record the time of disabling, and confirm that any downstream sync removed or disabled its access. Repeat the test after any configuration change. Where the process is manual, have the operator run the same steps and record them. The output is a dated test record with the account name, expected result, observed result and tester name, which is the test output assessors expect to see alongside the configuration.
Schedule a recurring review of disabled and near-limit accounts
Set a recurring review, at an interval your policy defines, in which the owner checks accounts that have been disabled, accounts approaching the inactivity limit, and any accounts that were re-enabled. Confirm each re-enablement has an approved request, and confirm that accounts with no business need are removed or kept disabled. For periodic access reviews, a certification workflow such as midPoint's access certification campaigns can route each item to a designated reviewer, who decides within a set timeframe whether to keep, change or revoke access. Confirm the review frequency in your own policy, since no fixed interval is supplied here. The output is signed review minutes or certification campaign reports for each cycle.
Retain the configuration, test output and review records
Collect the final policy, the system inventory and gap register, the configuration exports, the dated test record and the review outputs into one evidence folder with a version number and an owner. Confirm that every item is in final form, because drafts do not satisfy an assessment objective, and keep the change history showing when the setting changed and who approved it. Check that the evidence matches what the system currently does, since an assessor will compare the policy with the live configuration. Confirm your evidence retention period with your assessor or contracting office, as this page does not supply one. The output is an indexed evidence package ready for the system security plan and for an assessor's sampling request.

Evidence that shows identifiers are disabled after inactivity

SP 800-171A names the evidence an assessor looks for under 3.5.6: the procedures that set the inactivity period, the account lists, and tests of the mechanism that disables identifiers. The cards below cover each artifact, plus how to keep it current between assessments.

Identifier and account management procedure

This written procedure states the inactivity period your organization has defined, who owns the disabling step, and how exceptions are approved. Assessors check it against the first assessment objective, which requires a defined period after which an identifier is disabled. Confirm that the period in the procedure matches the period configured in your directory or identity platform. A mismatch between paper and configuration is one of the most common findings. Record the version and approval date on the document.

List of system accounts with last-activity data

Export every account on in-scope systems with its last logon or last activity timestamp, its status, and its owner. This list shows the assessor which accounts have passed the defined inactivity period and whether they were disabled. Include service and shared accounts, and mark those that are exempt with the approving record. Accounts with no recorded activity still need a clear status. Export the list directly from the directory rather than retyping it.

Configuration exports of the disabling mechanism

Provide exports or screenshots of the setting or policy that disables inactive identifiers, such as an automated rule in your directory, identity provider or provisioning connector. The assessor needs to see the inactivity threshold, the scope of the rule, and the action it takes. Keep a dated export for each review cycle. If a connector such as an automated provisioning tool removes users from downstream applications, export its configuration as well so the disabling reaches every system in scope.

Test records of a disabled account

Test records show that the mechanism works in practice. Pick a test account, let it pass the defined inactivity period or simulate that condition in a test environment, then record the time it was disabled and confirm that logon fails. Save the ticket, log entry or screenshot that shows the result. This addresses the second assessment objective, which requires that identifiers are actually disabled after the period. Repeat the test after any change to the directory or provisioning configuration.

Identifier list from physical access control devices

Where physical access control devices generate identifiers, such as badge or card systems that feed user records into your environment, SP 800-171A lists the identifier list from those devices as potential evidence. Show which badge identifiers exist, when each was last used, and that inactive badges are deactivated on the same schedule as system accounts. If your organization has no such devices in scope, record that decision in the procedure so the assessor does not need to ask.

Dated records that keep evidence current

Assessors judge evidence on whether it is final and current. Date every export, keep change records for the inactivity setting and the procedure, and file each periodic account review with its reviewer and outcome. Drafts do not count as final evidence, so finalize and sign each record before the assessment window closes. Ask your assessor early which evidence format and retention period they expect, because those expectations shape how you name and store the files.

What meeting IA.L2-3.5.6 costs in effort and licenses

This table compares the cost components of meeting IA.L2-3.5.6, showing who is paid for each, whether it is one-time or recurring, what drives it up, and how to reduce it. Use it to build a quote request, since no price for any component is published here and the only fixed figures are the scoring facts for this requirement.

Cost component	One-time or recurring	What drives it	How to reduce it
Configuration engineering for the disabling logic	One-time, with periodic changes	Number of identity sources, applications and account types, and whether disabling is automated or manual	Standardize on one identity source, define the inactivity rule once, and document it as a policy the platform enforces
Last-activity data gaps across systems	One-time remediation, then recurring checks	Systems that do not record last login, service accounts with no interactive logon, and physical access badge identifiers	Inventory which systems expose last-use data before designing the rule, and record an agreed fallback for systems that do not
Directory or identity platform licenses	Recurring, unless the platform is open source	Per-user or per-device licensing terms in commercial products, and the number of accounts in scope	Compare commercial terms with self-hosted open-source options, but confirm support and upgrade costs with the vendor or partner
Periodic account review time	Recurring	Number of accounts, frequency of reviews, and how many reviewers must sign off	Generate the account list automatically, pre-flag accounts past the inactivity period, and limit reviewers to exception decisions
External review or testing	Recurring or per engagement	Scope of the test, whether accounts and dormant identifiers are tested, and the size of the environment	Fix the scope in writing before work starts and test the disabling mechanism with a sample of dormant accounts
Assessor sampling of the account list	Recurring at each assessment	Completeness of the account list, quality of identifier management procedures, and how well test results are recorded	Keep account lists, procedures and test records current and in final form, since drafts do not count toward a MET result
Self-hosted open source in place of license spend	Removes recurring license spend only	Engineering, hosting, upgrades, documentation and review effort still apply in full	Treat license savings as separate from effort, and budget staff time for the disabling rule, reviews and evidence

Which open-source identity tools can automate account disabling

Disabling an identifier after a defined inactivity period depends on knowing who last used an account and having a process that acts on it. The three open-source tools below cover different parts of that chain: a directory of accounts, a provisioning engine that removes access downstream, and a review workflow that forces a decision on dormant access. None of them proves compliance alone, and each needs configuration confirmed in your own environment.

FreeIPA as the account directory

FreeIPA, licensed under GPL-3.0-or-later, stores users, groups and hosts in 389 Directory Server, a multi-master LDAPv3 directory, and offers centralized access control with delegated administration through its web UI and command line tools. For IA.L2-3.5.6, the directory is the system of record that an assessor will ask for: the list of system accounts and the identifiers it holds. Confirm whether your deployment records last-login data per account and whether it can disable an account on a schedule tied to that data, since the directory itself does not define your inactivity period.

authentik SCIM deprovisioning

The authentik SCIM provider, released under the MIT license, 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. This helps with 3.5.6 because a disabled identifier should not survive in downstream applications. Confirm that the provider can act on inactivity rather than only on removal of access, and test that an account disabled in the source is also disabled in each target.

midPoint access certification reviews

midPoint, licensed under EUPL-1.2+, runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This produces a documented review record, which assessors look for as account review evidence. It does not detect inactivity by itself, so confirm that your campaigns include last-used or dormancy criteria, that reviewers receive the data they need, and that revocations are carried through to the systems that hold the accounts.

How to choose the inactivity period without copying the 45-day example

The CMMC Assessment Guide for Level 2 uses an example policy that disables any account not used in the last 45 days. That number is an illustration, not a requirement. IA.L2-3.5.6 asks the organization to define its own inactivity period and then disable identifiers when that period passes, so an assessor will look for a period your organization chose deliberately and can justify. Copying 45 days without analysis gives the assessor nothing to test your reasoning against. Start from your system's risk and account population instead: how exposed the system is to remote access, how sensitive the CUI in it is, and how many accounts sit outside normal joiner and mover processes such as contractor, vendor and project accounts.

Account types should set different periods rather than one number for everything. A false disable of a service account can stop a batch job, an integration or a backup process at an inconvenient hour, so these identifiers usually need a documented owner, a longer or exempt window, and a separate review trigger. Human accounts tied to an HR feed can often follow a shorter period, while accounts that are used only occasionally, such as quarterly reporting or emergency administrator access, need a period that does not catch them in normal gaps. Ask your identity team to produce a report of last-use dates by account type before setting the number, and confirm with each system owner how their identifiers are used. Your identity platform and directory should be able to report last-logon data, but confirm that field exists and is accurate in your environment before you rely on it.

Document the rationale, the review cadence and the exceptions process in the system security plan or the account management procedure. The record should state the chosen period, the risk factors behind it, the account types it applies to, who approves exceptions, how long an exception may last, and how exceptions are re-reviewed. Schedule periodic reviews of the period itself, especially after changes to remote access or to the user population, and keep the review output as evidence. Assessors testing the two assessment objectives for 3.5.6 will look for a defined period and proof that disabling happened after that period, so a dated decision record plus a sample of disabled accounts is far stronger than a number with no history behind it.

Who owns the inactivity control, who can help, and who assesses it

Your organization owns IA.L2-3.5.6. Leadership and the security function must decide the inactivity period, write it into the identifier management policy, and make sure the disabling mechanism actually runs. An implementation partner can build the mechanism, but the period is a risk decision that belongs to you, and so does proving that accounts are reviewed. Assessors look for an owner who can explain the rule and show it working.

Setting the period: Define the inactivity threshold in a written policy and record who approved it and why. The CMMC Assessment Guide uses a 45-day example, which is illustrative only; your own threshold should reflect your risk and the systems involved.
Owning the disabling mechanism: Keep an accountable administrator for the directory or identity provider settings that disable idle identifiers.
Running account reviews: Schedule and sign off periodic reviews of active system accounts, and record exceptions for service and emergency accounts.
Keeping the policy current: Update the identifier management procedure when systems, identity sources or contracts change.
Retaining records: Preserve dated configuration exports, review sign-offs and disable logs.

Before any engagement, confirm that the named owner, the approved period and the review cadence are written down.

Where inactive-account controls usually fall short

Most organizations have a sentence in a policy about disabling inactive accounts, yet assessors find the gap between that sentence and the running system. The cards below cover the failure points that recur under IA.L2-3.5.6 Identifier handling, each paired with a fix that produces evidence an assessor can test.

Policy names a period, nothing enforces it

A written policy often states an inactivity window, but no directory, identity provider or application setting actually disables accounts when that window passes. The first assessment objective requires a defined period, and the second requires disabling after it, so both must be visible in configuration. Check that the period in the policy matches a value set in the identity platform, then export the setting as evidence. Where a period is set in a directory, record the attribute or policy name that enforces it. If the policy cites an example period from the CMMC Assessment Guide, state your own chosen value and the reason for it.

Last-use data split across systems

Last logon may be recorded in the directory, the VPN, the cloud tenant and individual business applications, and each one can disagree. An account that looks idle in one system may be active in another, so a disabling rule applied to a single source either misses accounts or disables people who still work. Decide which system is authoritative for last use, then document how the others feed it. Pull the list of system accounts with last-activity dates from each source during testing and reconcile the differences. Assessors reviewing identifier management procedures look for this reconciliation.

Service and shared accounts never age out

Service accounts, break-glass accounts and shared administrative logins often sit outside the joiner, mover and leaver process, so no inactivity rule touches them. They are attractive to an adversary because their use is rarely watched. Build a separate inventory with an owner, a purpose and an expected usage pattern for each one. Apply the inactivity rule to them as well, with documented exceptions approved by the owner for accounts that run on a schedule. The inventory and exception approvals become the account list evidence that assessors request.

Re-enabled accounts leave no record

Help desk staff often re-enable a disabled account when someone calls to say they are back from leave, and the change is made without a ticket or approval. The identifier then returns to service with no trace of who approved it or why it was dormant. Route every re-enablement through a ticketing workflow that requires the account owner's approval and records the reason. Configure the identity platform to log the change, and review those logs as part of the account review. Without that trail, the disabling control cannot be shown to work over time.

Disabling never tested

Teams often confirm that the configuration exists but never run a test account through the full cycle of inactivity, disabling and attempted logon. The second assessment objective concerns the mechanism working, so a setting that has never been exercised is weak evidence. Schedule a test using a dedicated test identity that is left unused for the defined period in a non-production environment, then capture the disable event and the failed logon. Keep the test record, date, tester and result together so they can be shown to an assessor.

Account reviews happen once

A single cleanup of stale accounts before an assessment does not show that the control operates continuously. Assessors expect the inactivity rule and the account list to be reviewed on a recurring basis, with the review record kept. Set a review cadence in the policy, assign an accountable owner, and keep signed or ticketed records of each review along with the accounts removed or retained and the reasons. Where a midPoint-style access certification campaign is used, the reviewer decision and timeframe become the record. Confirm the cadence against your own risk assessment and your assessor's expectations.

Questions about IA.L2-3.5.6 cost, effort and readiness

How much effort does IA.L2-3.5.6 take for a small team?

For most small teams the effort is modest in concept but real in practice, because the requirement is worth 1 point and the work is mostly configuration and review rather than new technology. The work has two parts: setting a documented inactivity period and making sure accounts are disabled automatically when they pass it. Effort rises when accounts are spread across several systems with no central directory, when service and shared accounts are not inventoried, or when no one owns the account list. Effort falls when identities come from one directory or identity provider that can disable accounts on a schedule. Ask any partner to estimate effort against your actual account inventory, because the count of systems and identity sources matters more than headcount.

Can we meet IA.L2-3.5.6 without outside help?

Yes, an organization can meet this requirement with its own staff, since it owns its controls and the assessor is independent. The work needs an identity or systems administrator who can configure the directory or identity provider, a policy owner who can set and approve the inactivity period, and someone who keeps the evidence current. Staff should be able to produce the account lists, the identifier management procedure, test results showing that an inactive account was disabled, and records of periodic account reviews. Outside help is most useful where the team lacks directory experience or where the inventory of accounts is incomplete. Any outside party should prepare systems and evidence only, never write the evidence as if it were the assessor's finding.

How long does the IA.L2-3.5.6 work take?

The timeline depends on how many identity sources, applications and accounts must be covered, how much the account inventory needs cleaning up, and whether the organization can change its directory settings without a long change approval. Each of these can add weeks or months, so ask for a timeline only after a written scope exists. The one fixed figure in the regulation that you should plan around is the 180-day closeout window that applies if the requirement is placed on a POA&M, covered in the next question. Ask any partner to show how the schedule accounts for testing a disabled account, collecting the review record and getting evidence into final form before an assessment.

Can IA.L2-3.5.6 go on a POA&M, and what does the scoring rule say?

Yes, under the scoring rules in 32 CFR 170.24 this 1-point requirement is not on the exclusion list in 32 CFR 170.21, so it can be placed on a plan of action and milestones when the overall score is at least 88 of 110, which equals 0.8. Closeout is due within 180 days. Confirm the current status of the Level 2 phases and the POA&M rules before relying on this option, because the Department of War suspended Phase II in July 2026 and the status of conditional awards may change. A POA&M is a documented plan, not a waiver, and an assessor will expect the mechanism to exist and be tested when the item is closed.

What does a partner need from us to scope this requirement?

A partner needs enough information to define the boundary and the accounts in it before quoting. Prepare the following:

A list of every system, application and cloud tenant that holds CUI or can reach systems that do.
The identity sources, such as directories, identity providers and local account stores, and which applications they feed.
The current policy for inactive accounts, if one exists, and who approves it.
A list of service accounts, shared accounts and accounts generated from physical access devices, with their owners.
Any existing account review records and the tools used to produce them.

With this, a fixed-scope proposal can state what is in and out, the deliverables and the timeline. DeployOpen plans and implements in the client's own infrastructure and agrees scope in writing before work starts.

Can the assessor help us configure the disabling of inactive accounts?

No. An assessor or C3PAO must remain independent of the organization it assesses, so it cannot design, configure or operate the controls it will later test. The assessor can explain what evidence it expects and test whether the mechanism works, but the configuration work belongs to the organization or to an implementation partner it hires. Keeping those roles separate is what gives the eventual result its value. If you need help, engage a partner for the configuration and evidence preparation, then ask the assessor to test the result independently.

How DeployOpen scopes, configures and documents identifier handling

DeployOpen works on IA.L2-3.5.6 Identifier handling as a fixed-scope implementation inside the client's own environment. We set the inactivity rule the organization approves, configure automated disabling where the platform supports it, and produce the account lists and review records an assessor will ask to see.

How we scope

The written scope names every directory, identity provider and application where accounts are created and used.
The organization decides the inactivity period in its own policy, and the scope records that value and its owner.
The scope lists which account types are covered, including user, service and process identifiers, and which are excluded.

How we build

We configure the chosen open-source identity platform so disabling runs automatically once an account passes the defined inactivity period.
Deprovisioning is set up for connected applications so that removing access upstream also removes it downstream.
We test the mechanism with sample inactive accounts in a non-production environment and keep the test results for the evidence file.

How we hand over

You receive the identifier management procedure, the system account list and the configuration exports the assessor will examine.
Periodic account review records are documented with reviewer, date, decision and follow-up for each disabled or retained account.
Runbooks explain how the organization confirms the rule still runs, and how it reviews exceptions and reactivation requests.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Support can cover changes to the inactivity period, new connected applications and periodic evidence refreshes.
Before any assessment, confirm with your assessor which evidence formats they accept and which parts of the record they expect to see.