03.01.22 Publicly accessible content: evidence and audit

What 03.01.22 publicly accessible content requires before anything goes live

Publicly accessible content under 03.01.22 is the requirement that keeps controlled unclassified information off anything the public can reach. For a contractor, that means the company website, a careers portal, a public knowledge base or wiki, a press page, or a social media feed linked to the organization. The requirement asks for three things: train the people authorized to post content so they know that publicly accessible information must contain no CUI, review content on publicly accessible systems for CUI, and remove anything found. The risk is rarely a deliberate leak. A project manager pastes a technical drawing into a blog post, a recruiter attaches an internal statement of work to a job listing, or a support engineer copies a system diagram into a public help article. Each of those can expose CUI to anyone with a browser.

This is hard in practice for three reasons. Many people can publish, often informally and without a second reader. Content on a public site changes after it was reviewed, through edits, plugins, file uploads and comments. And the people who post may not think of themselves as publishers at all. A workable starting point is to write down who is authorized to post, which sites and systems count as publicly accessible, and what a reviewer checks for, then confirm that list with the contracting officer or your CUI program lead, since the definition of CUI for your contracts comes from the contract and the CUI categories, not from your own judgment.

Rev. 3 treats this requirement as a significant change from Rev. 2 requirement 3.1.22. The Rev. 2 to Rev. 3 change analysis describes it as more detailed, with foundational tasks added, so a Rev. 2 checklist will not cover what an assessor now looks for. The requirement sits in the 03.01 access control family, which is why the assessment usually draws on your access control policy and procedures, the list of authorized posters, training records and the mechanisms that manage public content. Confirm the current assessment objects in NIST SP 800-171A Rev. 3 before you build evidence, because the assessor will test against that document.

Which public channels and posting roles fall under 03.01.22

Before any training or review can be planned, the organization has to decide which of its public-facing channels count as organizational systems and who is authorized to put content on them. Each decision below changes how many people need training and how much content must be reviewed for CUI on a recurring basis.

Corporate websites and public portals

Start by asking whether the public website runs on, or is managed through, a system the organization operates or contracts for. Marketing sites, customer portals, and download pages all fall here when the organization controls what is published. Check whether any page is generated from internal data, such as project pages built from a contract database or a case study pulled from a shared drive. Each content source that feeds the site adds a review point. A narrow site with one publishing workflow needs a short list of posters and a single review step, while a site with many feeds needs review at each feed. Confirm which team owns the content management system and who holds publish rights.

Public file shares and document libraries

Public file shares, open download folders, and shared links to cloud storage can expose CUI without anyone noticing. Ask whether any folder is reachable without authentication, whether anonymous share links are permitted, and whether link expiry is enforced. A file uploaded for a partner may carry CUI markings that no one removed. Because these channels accept uploads from many staff, the review load grows with volume and is hard to bound. Many organizations restrict public sharing to a small set of approved tools and require a named owner for each published file. Confirm which share settings are reachable from the internet and who can change them.

Social media accounts and official channels

Official social media accounts are publicly accessible systems when the organization posts or manages them, and posts are often drafted quickly under time pressure. Ask who holds login credentials, whether posting tools are connected to internal systems, and whether employees post from personal accounts on the organization's behalf. Images, screenshots, and event photos can carry CUI in the background or metadata. The posting population here is usually larger than the marketing team, so training must reach every account holder. Confirm whether shared credentials exist and whether posting requires approval before publication.

Public wikis and documentation sites

Public documentation, developer portals, and knowledge bases are often edited by engineers who assume that internal detail is harmless. Architecture notes, configuration examples, and error logs can reveal details about a CUI system. Ask which documentation spaces are public, which are internal, and whether any internal space is accidentally exposed through a sharing setting. Version history matters here: a page removed from view may remain recoverable, so the removal step must cover history where the platform keeps it. Wiki platforms that record every change, compare versions, and roll back to earlier ones make it easier to trace when CUI first appeared. Confirm which spaces are public and who has edit rights in each.

Executive and HR communications

Executive speeches, investor updates, and recruiting pages draw on sensitive material such as contract values, program schedules, and staffing details. Ask whether these items are authored by people outside the security or compliance chain and whether they pass through a review step before publication. HR postings and benefits pages can contain personal data or program detail tied to CUI-bearing work. Because these authors are often senior or unavailable for training sessions, the organization may need a short briefing and a clear pre-publication checklist for them. Confirm which executives and HR staff can publish, and whether their content requires a second reader.

Third-party hosted pages

Pages hosted by a vendor, such as a hosted blog, event platform, or job board, still carry the organization's content, but the organization may not control the platform's system. Ask whether the vendor is an external system under the organization's own agreements, and whether those agreements define who reviews content and who removes it. Content that the organization uploads to a third-party platform remains within 03.01.22 scope for review and removal, even when the vendor's servers are outside the boundary. Confirm the vendor's contractual terms, the ability to remove content and its history, and which staff can publish to the platform.

How an assessor tests publicly accessible content

This table compares the three SP 800-171A Rev. 3 determination statements for 03.01.22 by assessment method, showing what the assessor examines or asks, the evidence to prepare and the findings that commonly appear. Read each row as a checklist for what your team should have ready before an assessment begins.

Method	What the assessor examines or asks	Evidence to prepare	Common findings
Examine: policy and procedures	Whether the access control policy and the procedures for publicly accessible content define who may post, what review happens before posting and how discovered CUI is removed	Approved access control policy, written procedure for publicly accessible content, version and approval dates	Procedure exists but does not name a reviewer or a removal step, or was never approved
Examine: authorized poster list	Whether a current list of users authorized to post publicly accessible content on organizational systems exists and matches who actually holds posting rights	Named list with roles, approval records, and a comparison against the web content management system's user roles	No current list, or accounts with posting rights that do not appear on the list
Examine: training materials and records	Whether training covers recognizing CUI and the review steps, and whether completion records exist for each authorized poster	Training content, completion records by person and date, refresher schedule	Training materials exist but no completion records, or training predates the current procedure
Interview: personnel who manage public information	Whether content owners can describe what counts as CUI, how they review pages and what they do when they find CUI	Interview notes gathered by the assessor, supported by a walkthrough of a recent review	Staff describe a review step that is not in the written procedure
Interview: information security personnel	How security staff monitor public systems for CUI, how findings are escalated and who approves removal	Escalation path, monitoring or review records, incident or ticket examples	Security staff are unaware that public content review is their responsibility
Test: content management mechanisms	Whether the mechanisms that publish or manage public content enforce the approval and review steps described in the procedure	Screenshots or configuration exports of publishing approvals, role permissions and version history for public pages	Any user can publish directly, so the approval step exists only on paper

Building the publish, review and remove cycle in order

This sequence turns 03.01.22 from a policy statement into a working cycle: named posters, a written procedure, trained people, a CUI check before anything goes live, periodic sweeps of published content, and a logged path for removal and reporting. Each step ends with a record an assessor can examine.

Name who may post and approve content
Start by deciding which people may place content on publicly accessible systems, such as the website, public file shares or social media accounts, and who must approve it before it goes live. Record these individuals in a named list of authorized posters with their role and the systems they may use. Confirm the list with the owner of each public system, then remove any shared or unknown accounts that could post. The output is an approved poster and approver list that the assessor will compare against actual access to the systems.
Write the publicly accessible content procedure
Write a procedure that tells posters and reviewers how content is prepared, who reviews it for CUI, how approval is recorded, how published pages are swept, and where the removal and reporting steps live. Tie it to the access control policy so the assessor can trace the requirement from policy to procedure to practice. Assign an owner and a review date, and have the system security plan reference it. The output is an approved procedure, version controlled and accessible to everyone on the poster list.
Train authorized posters and keep completion records
Train every person on the poster list before they are granted posting rights. The training should explain what CUI looks like in practice, how the organization marks and handles it, why public content must be free of it, and how to use the review and removal steps. Track completion in a learning platform or a signed attendance record, and refuse posting rights to anyone who has not completed the training. The output is training materials and per-person completion records that match the poster list.
Add a CUI review before publication
Before any item is published, a second person who is not the author checks it against a written review checklist. The checklist should cover CUI markings and handling indicators, controlled technical information, personal or contract details, unreleased program information and attachments with hidden metadata. The reviewer signs off or returns the item, and the approval is kept with the item. The output is a completed checklist for each published item, which shows the review happened before publication, not after.
Sweep already-published content on a set schedule
Publication review does not catch content that was posted earlier or that changed after approval. Set a review frequency for sweeping public systems for CUI, define the scope of each sweep (pages, documents, media, search index and cached copies), and assign the people who perform it. Confirm the frequency with your assessor and your contracting officer, because the requirement asks for periodic review and the organization sets the interval. The output is a dated sweep record listing what was reviewed, by whom, and what was found.
Remove CUI and log the finding
When a sweep or any other person finds CUI on a public system, remove the content from the public view promptly, preserve the removed version for investigation, and check whether copies or caches remain. Open a ticket or incident record that states what was found, where it was, how long it was public where known, and who removed it. Review the cause with the poster and update the checklist or training if a gap appeared. The output is a removal log entry for each finding, linked to the sweep or report that surfaced it.
Report the event to the incident process
Decide early whether a CUI exposure on a public system is also a reportable cyber incident under the contract. Route it through the incident response plan, and where the contract incorporates DFARS 252.204-7012, confirm with counsel the reporting timelines that apply. Keep the incident record connected to the removal log so the two tell one story. The output is an incident report or a documented decision that the event does not meet the reporting threshold, reviewed by the responsible officer.

Evidence that shows authorized posters are trained and content is reviewed

An assessor testing 03.01.22 wants to see a written rule, a named list of people allowed to post, proof that those people were trained, and records showing content was reviewed and removed when it contained CUI. Each artifact below answers one part of that chain, and each needs a refresh schedule so it stays accurate between assessments.

Access control policy and publication procedure

The access control policy sets who may place information on publicly accessible systems, and the publication procedure describes the steps from draft to live page, including who reviews for CUI before release. Assessors examine both documents, so they must name roles rather than individuals and match what staff actually do. Check that the procedure covers websites, social media, file shares that are exposed externally, and any vendor-hosted channels. Review both documents on a schedule the organization sets and after any change to the public web estate.

List of authorized posters

This is a named list of the users permitted to publish or edit publicly accessible content, tied to their roles and the systems they can reach. Assessors compare it against the actual accounts on the content management system, so any account that can publish but is missing from the list is a finding. Recertify the list on a schedule the organization sets, and remove posters when they change roles or leave, using the same triggers as account deprovisioning.

Training materials and completion records

Training for authorized posters should explain what CUI looks like in the organization's contracts, how to recognize it in drafts and attachments, and who to escalate to. Keep the slide decks or course content with a version date, plus a record for each person showing completion and date. An LMS with completion tracking can generate these records automatically, so confirm that the reports export cleanly for an assessor. Retrain when the CUI marking rules or the publication procedure change.

Content review records

Review records show that content on publicly accessible systems was checked for CUI, with the reviewer, date, scope and result for each sweep. A periodic sweep of public pages and document libraries, logged as a dated record, gives the assessor evidence that the review runs and not only that it was described. Link each sweep to change records where new pages or uploads triggered it, so the log shows both scheduled and event-driven reviews.

Removal records with dates and reasons

When a review finds CUI, the removal record should state what was found, where it appeared, the date it was taken down, who removed it, and the reason. Keep the removal tied to a ticket or change record, and note whether any cached copies, search indexes or archived versions were cleared. Assessors look for removals that are logged, not only assumed, so a clean history of removals is evidence the process works.

Interview-ready role descriptions

Assessors interview personnel with responsibilities for managing public information, so each person should be able to describe what they publish, how they check it for CUI, and what they do when they find a problem. Write a short role description for each function, confirm that people can explain it without reading from a script, and check it against the policy and procedure. Refresh the descriptions whenever responsibilities move between teams.

What meeting 03.01.22 costs in money and effort

This table breaks the work of meeting 03.01.22 into cost components, showing who is paid, whether each cost is one-time or recurring, what pushes it up and how to contain it. No prices are published here, so use the drivers to shape your scope and the questions to put to any quote.

Cost component	One-time or recurring	What drives it up	How to keep it down
Access control policy and public content procedures	One-time to write, periodic to review	Number of public channels, number of publishing roles, and whether the procedure is written separately for each site or team	Write one procedure covering all public channels, and tie the review cycle to the existing policy review
List of authorized posters	Recurring	Staff turnover, number of departments with publishing rights, and how often the list changes	Grant posting rights through named roles in the platform, so the list is generated from role assignments
Training design and delivery for authorized posters	One-time build, recurring delivery to new posters	Number of authorized posters, number of tools they use to publish, and whether training is built from scratch	Reuse general CUI training content and add a short module on the publishing workflow, then record completion
Training records and completion tracking	Recurring	Learning management system licensing, the number of learners, and manual record keeping	Use the training platform's completion tracking so records are generated automatically and retained for the assessor
CUI review step before publication	Recurring, scales with publishing volume	Volume of posts, length and complexity of documents, and how often reviewers must escalate to the CUI owner	Add a checklist and a named reviewer, and route only items that need a marking decision to the CUI owner
Reviewer time for publication review	Recurring	Number of reviewers, review queue size and turnaround expectations for public releases	Keep review in a versioned workflow so reviewers compare drafts instead of re-reading whole pages
Periodic sweeps of public content	Recurring	Number of public websites, file repositories and third-party hosted pages, plus how often content changes	Sweep the highest-change channels more often and sample the rest, and document the frequency you chose
Removal and incident handling for CUI found publicly	Recurring, unpredictable	Frequency of findings, whether removed content was cached or indexed, and whether an incident report is needed	Define removal steps in advance and link them to the incident response plan so each finding follows the same path
Tooling and licensing	Recurring license fees, or one-time setup for self-hosted tools	Number of seats, proprietary publishing or document management licenses and add-on modules	Self-hosted open-source wiki, document and learning platforms may remove per-seat license spend, but hosting, support and maintenance still need budget
External review or assessment support	Periodic, tied to assessment dates	Scope of public channels, condition of existing evidence and whether an independent assessor is engaged	Prepare the evidence before the assessment; an independent assessor issues any assessment result, not the implementation partner

Using Moodle, XWiki and BookStack for training, review and page history

Three self-hosted open-source platforms can each produce one part of the evidence for 03.01.22: training records, content review history and the list of people allowed to post. None of them makes the requirement met on its own. The organization still owns the policy, the review decisions and the assessment outcome, and an implementation partner can set up and document how each platform is used.

Moodle activity completion for training records

Moodle's activity completion can mark a training activity complete for each learner when they view it, when they receive a grade, or when they tick it manually. For 03.01.22, the assessor will look for training materials and records showing that people who can post public content were trained to keep CUI out of it. Choose the completion condition deliberately, because a view-only trigger records attendance but not understanding. Moodle is licensed under GPL-3.0-or-later, so confirm with counsel how that license applies to any modifications your team makes before you deploy it.

XWiki version history for review records

XWiki keeps version control for every page change, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This gives the organization a trail for reviews of public content, showing that a page was checked and that any CUI found was removed. The history only proves something if reviewers record their findings in the page or a linked ticket. XWiki is licensed under LGPL-2.1-or-later, so confirm the license terms for your deployment with your legal team.

BookStack roles for the authorized-poster list

BookStack assigns user abilities through roles and lets administrators override permissions per role at the shelf, book, chapter or page level. Used carefully, this lets you limit who can create or edit content in a public-facing area and export that configuration as the list of users authorized to post publicly accessible content. Review the role assignments on a set schedule and record each change. Confirm that BookStack's permission model matches how your public content is actually published, since a page-level override can grant more access than a shelf-level setting suggests. BookStack is MIT licensed.

Confirm fit before relying on any platform

Each of these platforms covers one piece of the evidence, and none is designed as a CUI control on its own. Before you rely on one, confirm with the vendor or community how it behaves in your environment, including how it handles backups, retention, authentication through your identity provider and logging of administrator actions. Check that any public-facing site is served from a system inside your authorization boundary. An implementation partner can map these platforms to your system security plan, but the organization decides what it accepts as evidence and the assessor decides whether it satisfies the requirement.

Who owns, implements and audits 03.01.22

Your organization owns 03.01.22. That means the policy that defines what may be published, the list of people authorized to post publicly accessible content, the people who review that content for CUI, and every decision to remove something found on a public system. No partner or assessor can make those decisions for you, and the assessor will ask named staff to explain how they work in practice. The assessment procedure for this requirement is built around three determination statements, so the people in this tab should be able to show each one with current records.

Policy and procedures: Maintain the access control policy and the publicly accessible content procedure, and keep them approved and dated.
Poster list: Keep a current list of users authorized to post to public systems, with a named owner who approves additions and removals.
Reviewers and removal decisions: Assign named reviewers who check content for CUI and record each removal and who authorized it.
Training records: Ensure authorized posters are trained before they publish and that completion is recorded.
Interview readiness: Make sure staff with responsibility for public content can explain the process without reading from a script.

Confirm with your contracting officer or assessment lead which systems count as publicly accessible in your environment before you finalize the poster list.

Where publishing controls usually fail 03.01.22

Assessors testing 03.01.22 usually find the same few gaps: nobody can show who is allowed to post, the people posting were never trained, and content goes live outside the approved workflow. The cards below pair each gap with the step that closes it, so the evidence the assessor asks for already exists when the assessment starts.

No list of authorized posters

Assessors look for a current list of the users authorized to post publicly accessible content on organizational systems. Without one, nobody can show that a given post was made by someone entitled to make it. Build the list from the accounts that hold publishing rights on each website, wiki space and file share, assign an owner to approve changes, and review it on a schedule the organization defines. Ask whether departed staff and contractors are removed from it.

Posters who never completed training

03.01.22 requires that authorized individuals be trained to make sure publicly accessible information contains no CUI. Assessors ask for training materials and completion records, and they check that the records match the authorized-poster list. Tie posting rights to a completed course, so a user cannot publish until the training is recorded. Re-training after a policy change should be tracked the same way.

Marketing and HR pages outside the workflow

Public pages often change through content management tools that the security team never sees, such as a marketing platform, a recruiting portal or a vendor-hosted landing page. Those pages fall under the same requirement as the main site. Inventory every system that serves content to the public, record which team owns each one, and confirm that each runs through the same review and approval steps before anything goes live.

Review only at publication

The requirement covers content on publicly accessible systems, which means content that is already live. Many programs check a page once before it is published and never again, so a document attached to an old article or a spreadsheet left on a download page can stay exposed for years. Schedule periodic reviews of live content against CUI markings and handling rules, and record what was checked, by whom and when.

Removal with no record

When a reviewer finds CUI on a public system, the organization must remove it, and an assessor will ask how the removal was done and whether anyone recorded it. Quietly deleting the file leaves no trail. Keep a removal log that notes the location, what was found, when it was removed, who approved the removal and whether the incident was reported under the organization's incident process. Check whether cached copies or search indexes still show the content.

Shadow channels outside the site

Social media accounts, hosted file links and shared cloud folders can make CUI publicly reachable even when the main website is clean. Staff often create these channels to move files quickly, and few are on any inventory. Search for public links and publicly shared folders tied to the organization, disable link sharing that anyone can open, and add these channels to the authorized-poster list and the review schedule.

Questions about 03.01.22 cost, effort and outside help

How much effort does 03.01.22 take compared with the rest of the access control family?

03.01.22 is one of the lighter requirements in the access control family, because its work is a recurring content review rather than a system build. Most of the other 03.01 requirements, such as account management (03.01.01), access enforcement (03.01.02) and remote access (03.01.12), require configuration in identity systems, network devices and endpoints, and each produces its own evidence set. For 03.01.22, the effort sits in three places: a short training module for authorized posters, a written procedure for reviewing public content, and a recurring review of websites, shared drives with external links and public document repositories. The scope of the review is what drives the effort. An organization with one public website and a small publishing team has a far smaller job than one with many public microsites, social channels and open file shares. Ask any consultant to scope the review by counting the publicly accessible systems and the people who can post to them.

Can a small team handle 03.01.22 without outside help?

Yes, a small team can usually meet 03.01.22 in-house, because the requirement is process-heavy and does not depend on specialist tooling. The core tasks are to decide who may post publicly, train those people on what counts as CUI, review public content for CUI, and remove anything found. A small team needs a named owner for the public content, a list of authorized posters, training records and a review log. The harder part is consistency: someone must check content on a defined schedule, not only when a complaint arrives. If the team lacks anyone with a clear view of what CUI looks like in its contracts, the first step is usually to confirm marking and handling rules with the contracting officer or internal legal counsel rather than guessing at the boundary.

What does 03.01.22 require from our own staff?

03.01.22 requires the organization to supply four things from its own people: an accountable owner, an authorized poster list, reviewer time and policy approval. The owner decides who may publish, keeps the list current and signs off on the procedure. Authorized posters must complete training that explains what CUI is and how to recognize it in public-facing text, images and attachments. Reviewers, who may be the same people or a separate content or security function, need protected time to check content before and after publication. Finally, leadership or the security governance body must approve the access control policy and the publication procedure, because the assessor will examine both. An implementation partner can draft the procedure, build the training materials and set up the review log, but the organization must own the people, decisions and approvals.

How long does it take to be ready for a 03.01.22 assessment?

Readiness depends on the drivers below, and the organization should ask for a written, scoped estimate rather than relying on a generic duration. The main drivers are how many publicly accessible systems exist, how many people can post to them, whether training and a review procedure already exist, and whether earlier content has ever been checked for CUI. Organizations that already run a content approval workflow and keep training records usually need less time than those starting from nothing. A clean-up of legacy public content can take longer than the new process itself, because each archived document must be reviewed. Ask the implementation partner to list the systems in scope, the review backlog and the approvals needed, and ask the independent assessor which evidence it expects to see before scheduling the assessment.

Is it worth outsourcing 03.01.22, and which parts should we outsource?

Outsourcing is usually worth considering for the parts that need specialist preparation, not for the day-to-day posting decisions. Good candidates include drafting the publication procedure, designing the training content, configuring the review log or document workflow, running a one-time scan or review of legacy public content, and preparing the evidence package for the assessor. Keep ownership of the authorized poster list, the approval of content, the decision about what counts as CUI and the ongoing review schedule in-house, because the organization is accountable for them under its contracts. DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and can prepare the systems and evidence for a compliance assessment, but it does not issue assessment results. Any engagement should be fixed in writing with the scope and deliverables agreed before work starts.

How does 03.01.22 affect our CMMC Level 2 score and POA&M options?

Under CMMC Level 2, 03.01.22 is assessed as AC.L2-3.1.22, which is worth 1 point in the 32 CFR 170.24 scoring methodology. The rule in 32 CFR 170.21 bars this practice from a plan of action and milestones, so it cannot be deferred as an open item to be fixed later. In practice, that means the publication controls must be working when the assessment takes place. Because a single unmet point is still a failed practice, organizations should treat 03.01.22 as a must-pass item and confirm the current scoring and POA&M rules directly in the eCFR text before planning. An assessor, not the implementation partner, decides whether the practice is met.

What is the biggest cost risk in 03.01.22?

The biggest cost risk is discovering CUI in legacy public content after the process is in place, because the review and removal work is open-ended. Public websites, archived PDFs, shared links and old presentations can all hold material that was never reviewed. Costs rise with the volume of content, the number of contributors who published without training and the number of tools involved. To limit this, ask for an inventory of public systems and a sample review before agreeing to a full scope, and agree in writing how many items the first review covers and how additional items will be priced.

How DeployOpen scopes, implements and prepares evidence for 03.01.22

DeployOpen works on 03.01.22 by preparing the systems, procedures and records that show CUI stays off public websites and other publicly accessible systems. The organization keeps ownership of the requirement, its people and its publishing decisions, while DeployOpen helps build the review workflow, training records and removal process that an assessor will examine.

How we scope

Engagements are fixed-scope, with the publicly accessible systems, content owners and posting workflows named in writing before work starts.
The written scope lists which websites, portals, file shares and collaboration spaces count as publicly accessible for the assessed environment.
Scope also confirms which people are authorized to post content and which ones will be trained and interviewed.

How we build

Set up a self-hosted content platform inside your own infrastructure with role-based posting permissions limited to the authorized list.
Configure review and approval steps so that content on public sites is checked for CUI before publication.
Build version history and page-level permissions so every change to publicly accessible material can be traced to a person and date.

How we hand over

Deliver written procedures for publicly accessible content, including the review checklist and the steps for removing CUI found after posting.
Provide the authorized poster list, training materials and completion records that an examiner would ask to see for this requirement.
Document the test steps used to confirm the mechanisms work, so your team can repeat them at a defined frequency.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Ask whether your scope includes periodic re-review of public content and refresher training for new posters.
Confirm with your assessor which evidence they expect, since the independent assessor, not DeployOpen, decides whether the requirement is met.