AU-13 Monitoring for information disclosure explained

AU-13 monitoring for information disclosure: what the requirement asks

If you have been told AU-13 applies to your system, or you are tailoring a baseline and found it missing, the core ask is this: the organization must monitor open-source information and sites for evidence that its own information has been disclosed without authorization, and when something turns up, notify the people you have named and take the additional actions you have defined. The control is in the Audit and accountability family, but its subject is outside your systems. Think public code repositories, paste sites, social networks, forums and similar public locations where credentials, source code, customer records or internal documents may appear.

The risk is concrete. A developer pushes an API key to a public repository, a support export lands on a file-sharing site, or an internal architecture diagram is posted to a professional networking profile. Each of these can expose data long before anyone inside the organization notices. AU-13 does not prescribe what to search, how often, or what to do. Those values are organization-defined parameters, meaning you choose the frequency, the sources and the responses, then document them and show you follow them. NIST's Rev. 5 catalog gives the parameter structure, but the choices are yours and should be justified against your data classification and threat model.

Most of the difficulty is in decisions, not software. You must settle which keywords, domains, code namespaces, employee identities and data types count as your information, how often each source is checked, who triages a hit, how a confirmed disclosure reaches incident response, and what takedown or credential rotation steps follow. Confirm with your assessor and your own environment which of these your policy already covers, because the same monitoring feed can satisfy the control on paper and still fail an assessment if no one owns the response. Tooling comes later and should follow those decisions.

Where AU-13 monitoring for information disclosure applies

AU-13 has no SP 800-53B baseline, so the first question is whether your authorizing official or compliance owner has tailored it into scope. Once it is in scope, the work is shaped by four choices: what counts as organizational information, which open sources are watched, who acts on findings, and which third parties hold data that could leak.

Defining organizational information

Start with a written list of the information categories that count as organizational information for this system: customer records, source code, credentials, network diagrams, unreleased financial results and internal hostnames. Each category needs an owner and a keyword or identifier set that a monitor can match, such as domain names, employee email patterns, project code names and internal IP ranges. Without this list, the monitoring has nothing defined to look for, and an assessor will ask how the scope was chosen.

Choosing the monitored open sources

AU-13 requires the defined sources and sites to be named. Typical candidates include social networks, public code repositories, paste sites, public cloud storage buckets, job boards and vendor or community forums. Record each source, why it is in scope, how often it is checked and the method used, whether a manual search, a feed or a tool. A source that is left out should have a documented reason, since the choice itself is part of what an assessor reviews.

Assigning monitoring ownership

Decide which team runs the monitoring, which team triages hits and who is notified when a disclosure is confirmed. Security operations often owns collection, legal or privacy staff own disclosure decisions involving personal data, and engineering owns takedown of leaked code or credentials. Write these handoffs into the procedure, because AU-13 expects defined personnel to be notified and defined actions to follow, and interviews under SP 800-53A will test whether those people know their role.

Third parties and cloud providers

Data often leaks through parties outside the organization: SaaS vendors, managed service providers, outsourced developers, cloud accounts and contractors who hold copies of internal material. Inventory which of these hold organizational information, confirm contract terms for reporting suspected exposure, and decide whether their public footprints fall under the monitored sources. Cloud storage misconfiguration is a common route, so the monitoring scope should cover the organization's own provider accounts as well as third-party accounts.

Tailoring AU-13 into scope

No SP 800-53B baseline (low, moderate, high or privacy) selects AU-13 or its three enhancements, so the control enters a system's scope only when it is added through baseline tailoring or an overlay. Document the rationale in the system security and privacy plan and confirm the decision with your authorizing official or compliance owner before work begins. If AU-13 is left out, record that decision and the risk accepted for it.

Handling findings and escalation

Each confirmed or suspected disclosure needs a defined path: preserve the evidence, notify the named personnel, contain the exposure and decide whether incident response or breach notification duties apply. Define a severity scale for hits, since most findings will be false positives or low-value mentions. Link the AU-13 workflow to the incident response plan so that disclosure findings are tracked, retained and reported in the same way as other security events.

How an assessor tests AU-13 monitoring for information disclosure

This table maps the three SP 800-53A determination statements for AU-13 to the examine, interview and test methods and their objects. Read each row as a question the assessor will ask, the records or people they will ask for, and the gap that most often leads to a finding.

Assessment element	Objects and evidence requested	Common finding
Determination statement 1: monitored open-source information and sites are defined	Examine: the defined list of open-source information sources and sites (social networks, code repositories, paste sites, public cloud storage), the defined monitoring frequency, and the approved scope of organizational terms searched	Sources and frequency exist only in a policy draft or are never approved, so the assessor cannot tell what was supposed to be monitored
Determination statement 2: monitoring is performed at the defined frequency for evidence of unauthorized disclosure	Examine: monitoring records and system audit records showing each run, its date, the sources checked and the search terms used. Test: the mechanisms that run the monitoring, such as scheduled searches or a threat intelligence feed workflow	Monitoring is described in policy, but the records show no runs, gaps longer than the defined frequency, or runs that cannot be traced to a named analyst or tool
Determination statement 3: defined personnel are notified and defined additional actions are taken when disclosure is found	Interview: personnel responsible for monitoring open-source information and sites, who describe triage and escalation. Examine: notification and case records for each finding, with actions taken and closure. Test: alerting or ticketing mechanisms that route findings	Findings are reported in chat or email, but no ticket, notification record or closure note exists, so the assessor cannot confirm that defined personnel were told or that actions followed
Interview objects: personnel with monitoring responsibilities	Interview the analysts or team leads who run open-source searches and review results. Ask how they choose sources, handle false positives and decide what counts as organizational information	Staff describe monitoring informally, cannot name the defined sources, or are unaware the control is assigned to them
Interview objects: personnel with security and privacy responsibilities	Interview the CISO, privacy officer or incident response lead about who receives disclosure findings, how privacy-relevant data is handled during review, and how results feed incident response	Privacy and security owners have not reviewed the monitoring scope, so personal data found in public sources is handled without a documented process
Test objects: mechanisms implementing monitoring	Test the configured search, crawler or threat intelligence tooling. Evidence includes the configuration, source list, query definitions, exports of matches and access logs for the tool. Open-source examples include MISP, OpenCTI and Wazuh for ingesting and triaging intelligence and alerts	Tooling is installed, but saved queries are outdated, sources have been removed without a change record, or the tool was never tested on a known disclosure sample
Evidence that usually passes	Approved source list, dated monitoring logs, finding tickets with timestamps, notification records, closure notes and a documented review of the monitoring scope at a defined interval	Evidence is spread across personal notes or chat threads, which assessors often treat as insufficient to show repeatable operation

Implementing AU-13 step by step

This sequence turns AU-13 from a control statement into a working monitoring routine with named sources, owners, matching rules, response actions and a tested escalation path that an assessor can examine.

Define organizational information and sources in scope
List the organizational information that would cause harm if disclosed without authorization, such as source code, configuration files, customer data extracts, network diagrams, credentials and internal document names. Then list the open sources where that material could appear, including code hosting platforms, paste sites, social networks, public cloud storage listings and job postings. Record the owner of each information category and the reason each source is in scope. The output is a signed scope register that the monitoring team and the control owner both approve. Confirm with legal counsel which sources and collection methods are permissible in your jurisdiction before anything is collected.
Set monitoring frequency and defined personnel
Decide how often each source is checked and who receives findings and who acts on them. AU-13 requires the organization to define both values, so the control owner, security operations lead and privacy or legal contact should agree them in writing. Values are the organization's to set and should reflect the sensitivity of each information category and the volume of each source. Record the frequency and named roles in the control implementation statement. Confirm the role assignments against your incident response plan so that notifications do not go to people who are not on call.
Select the collection and matching method
Choose how evidence is gathered and compared to your scope register. Options include manual review by an analyst using saved searches, scripted searches against sources that permit automated queries, or a tool that ingests feeds and matches indicators. Manual review suits small source sets with low volume. Tooling becomes useful when the source list is long or the matching rules are complex. Open-source platforms such as MISP, OpenCTI, OpenSearch Security Analytics and Wazuh can hold matching rules, record sightings and retain alerts, but none of them collects open-source sites by default, so confirm which connectors or feeds you would need. Document the chosen method and its limits.
Set triage and notification rules
Write rules that separate noise from confirmed disclosure. Each rule should state what a match looks like, how an analyst confirms that the material is organizational and not a coincidence or public data, which severity applies, and who is notified. Include handling for personal data found in a match, because collecting and storing it may create privacy obligations. Test the rules against a sample of known-public and known-internal material to measure false positives. The output is a triage procedure with a severity scale and a notification matrix that analysts can follow without interpretation.
Define additional actions for each finding type
AU-13 requires defined additional actions when a disclosure is found, so write a response playbook for each finding type. Examples include takedown requests to a hosting provider, credential rotation, revocation of exposed keys, legal notice, customer or regulator notification assessment, and review of the leaked system for compromise. Assign each action an owner and a point at which it hands over to incident response under IR-4 or IR-6 if your program uses those controls. Record which actions require approval from legal or executive leadership. The output is a set of playbooks that match the severity scale from the previous step.
Run a tabletop test of the monitoring workflow
Walk the workflow end to end using a scenario prepared in advance, such as a configuration file with an internal hostname appearing in a public code repository. Observe whether the match is detected, triaged, escalated to the defined personnel and handled by the correct playbook. Record each decision, delay and gap, then assign remediation items to owners. Keep the scenario, attendee list, observations and corrective actions as evidence. An assessor examining AU-13 will typically look for proof that the defined process has been exercised, not only that it exists on paper.
Schedule review of sources and results
Set a recurring review of the scope register, source list, matching rules and playbooks, along with a review of recent findings and their outcomes. Changes in the business, new products, acquisitions, staff turnover and new public platforms should each trigger an update to scope. Record review dates, reviewer names, changes made and the reason for each change. Retain the outputs with the monitoring records so the program shows continuous operation. Ask your assessor or auditor which review cadence they expect for your authorization or certification.

Evidence that passes AU-13 and how to keep it current

An assessor testing AU-13 will look for proof that monitoring ran as defined, that findings were triaged, and that the organization acted on them. The cards below cover six artifacts that connect those steps, with a practical way to keep each one current between formal assessments.

Written monitoring scope

The scope document names the open-source sites and sources to be monitored, the categories of organizational information being searched for (such as domain names, code snippets, employee credentials, document markings and customer data), the monitoring frequency, and the personnel who own each source. AU-13 requires defined sources and a defined frequency, so an assessor will check that the scope is specific enough to test. Keep it under version control and record the approver and date of each change.

Monitoring run records

Each monitoring run should leave a dated record listing the sources checked, the search terms or queries used, the operator, and the results, including runs that found nothing. Gaps in this log are the most common reason an assessor cannot confirm the stated frequency. A recurring checklist or ticket per run, reviewed by a second person, makes missed runs visible before the assessment.

Findings list and triage decisions

Every potential disclosure should appear in a findings register with its source, the information involved, a severity, and a triage decision such as confirmed disclosure, false positive, or accepted risk with an owner. Recording false positives matters as much as confirmed cases, because it shows the monitoring is tuned rather than ignored. Ask the team to state the reason for each dismissal in one sentence.

Notification records

When a finding is confirmed, the defined personnel must be notified. Keep the notification message, its time, the recipients and any acknowledgment. Check that the recipients in the notification record match the roles named in the scope document, since an assessor may compare the two directly. Notifications sent through a shared channel should be exported or archived so they survive the channel's own retention settings.

Additional action and closure records

AU-13 also requires defined actions after a disclosure, such as takedown requests, credential rotation, legal review or customer notice. Track each action with an owner, a date opened, the evidence of completion, and a closure date. A finding that is open for an unexplained period is a visible gap, so set a review date for every open item. Link each action back to its finding record so the chain from detection to closure can be traced.

Periodic review of sources and frequency

The review record shows that the organization revisited its monitored sources and frequency after they were set, and adjusted them when business changes, new code repositories, or new public exposures appeared. Hold a quarterly review of the source list against current systems and products, and record what was added, removed or kept, with the reviewer's name. Between formal assessments, this record is what proves the control is maintained rather than set once.

What AU-13 monitoring for information disclosure costs

This table compares the cost components of running AU-13 monitoring, who is paid for each one, whether it is one-time or recurring, and what changes its size. Read it as a checklist for a quote: each row names what to ask the vendor, partner or internal team to price separately. No dollar figures or durations appear because none are supplied for this control, and the main takeaway is that the number of monitored sources and the volume of organizational information drive most of the recurring effort.

Cost component	One-time or recurring	What drives it up or down	What to ask for in a quote
Paid threat feeds or monitoring services	Recurring	Number of sources and sites watched, and whether feeds are licensed per seat, per source or per volume. Open-source collection lowers this line.	Itemized list of each feed or service, its licensing unit, renewal terms and what is excluded
Platform licensing (self-hosted option)	Recurring if commercial, none for the open-source platform itself	Choice of MISP, OpenCTI, OpenSearch or Wazuh removes license spend for the platform, but hosting and storage still apply	Confirmation of which components are open source and which add-ons or support tiers are priced separately
Engineering time to define search terms and matching	One-time, with periodic tuning	Number of organizational identifiers (domains, product names, code namespaces, staff addresses) and the matching rules needed to limit false positives	Scope of identifiers covered, the matching method used, and how tuning changes are billed
Integration of alerts into existing tooling	One-time, with recurring maintenance	Number of alert channels, ticketing or SIEM integrations, and whether alerts map to existing incident response workflows	Named integrations, test plan and whether maintenance after upgrades is included
Analyst time to run and triage findings	Recurring	Monitoring frequency defined by the organization, volume of candidate hits, and how much automated deduplication and sighting recording is in place	Expected triage volume assumptions, hours by role, and the escalation path to incident response
Takedown, legal and communications work	Recurring when incidents occur	Number of confirmed disclosures, jurisdictions involved and whether personal data is exposed, which brings in privacy counsel	Whether takedown requests, legal review or notifications are in scope, and who signs off on each
Evidence upkeep	Recurring	Frequency of review, retention period for monitoring records, and how many findings must be documented with actions taken	Evidence list the provider will produce, storage location and format, and how records are retained
External testing or review	Periodic	Depth of review of the monitoring design and whether an outside party tests that monitoring detects planted or known disclosures	Scope, deliverables and whether the reviewer is independent of the team that built the monitoring
Auditor sampling and assessment	Periodic, set by the assessor	Number of samples the assessor selects, which is tied to the organization's assessment scope and the three AU-13 determination statements	Confirm with the assessor which records they will sample and in what form they want them

Open-source tools that support AU-13 evidence

AU-13 asks for monitoring of open sources for unauthorized disclosure of organizational information, so the evidence is a record of what was watched, what matched and what was done about it. The three tools below cover different parts of that chain: indicator matching, threat intelligence organization and alert records. None of them replaces the collection step for social networks or code repositories, which the organization must confirm for its own sources.

MISP for indicator matching

MISP (AGPL-3.0-only) correlates indicators by exact match and by advanced patterns such as fuzzy hashes and CIDR overlaps, which helps when a leaked domain, hash or address needs to be matched against what the organization already tracks. It records sightings, so the team can show when an indicator was seen and by whom. Its REST API exports to STIX, CSV and Suricata, Snort and Zeek rule formats. Confirm whether your disclosure sources have an existing feed or need custom ingestion before relying on MISP for them.

OpenCTI for intelligence records

OpenCTI (Apache-2.0) organizes collected information as STIX-based entities and relationships, so a finding about a leaked credential or exposed document can be linked to the organization, the source and the response. It ingests data through connectors and through TAXII, RSS, CSV and JSON feeds or manual upload. Check the connector catalog for social network and code repository sources. Where none exists, the organization needs a custom connector or a documented manual collection procedure, with the collection date and source recorded.

OpenSearch Security Analytics findings

OpenSearch Security Analytics (Apache-2.0) runs detectors against ingested logs using Sigma rules and records each match as a finding with its rule, log type and severity. Alerts can go to channels such as Slack or email, and the correlation graph links findings across log types. For AU-13, a finding is a monitoring record only if the detector is tied to a disclosure source you actually collect. Confirm which log types you can feed into it and whether those sources include the open-source sites you have defined.

Wazuh alert records

Wazuh (GPL-2.0-only) decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus custom rules. Matches are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for dashboard review. These files can serve as a retained record of monitoring activity and responses. Confirm that the sources you need, such as a feed or scraped output from external sites, can be delivered to Wazuh as logs, since its built-in rules do not cover open-source sites by default.

In-house or partner: who does what for AU-13

Your organization owns AU-13 in full. AU-13 asks you to define the open-source information and sites to monitor, the frequency of monitoring, the personnel to notify and the additional actions to take when a disclosure is found. Those are policy and risk decisions, and no partner or tool can make them for you. Your team also keeps the risk acceptance record for anything you decide not to act on.

Defined sources and frequency: Name the code repositories, social channels, paste sites and other public locations you monitor, and set how often each is reviewed.
Defined personnel and response: Assign who receives a disclosure notice and who decides on takedown, legal referral, credential rotation or customer notification.
Keyword and asset scope: Decide which organizational information counts as sensitive, such as domain names, internal project names, employee identifiers and source code fragments.
Risk acceptance: Record why a finding was closed without action and who approved that decision.
Legal and privacy review: Confirm with counsel which collection activities are permitted on public sources and how personal data found in them is handled.

Confirm that these decisions are written into your policy and that the named owners know their duties before an assessor asks for them.

Where AU-13 programs usually fall short

AU-13 is not in any SP 800-53B baseline, so organizations that adopt it usually do so through tailoring or an overlay and then discover that the control has no working routine behind it. The gaps below share one root cause: the monitoring is claimed but not defined, run, recorded and tested in a way an assessor can follow.

Monitoring scope never written down

Teams often say they watch public sources for leaks but cannot list which sources, which organizational information, or which keywords and identifiers are in scope. AU-13 asks the organization to define the open-source information or sites it monitors and the frequency of monitoring, so an assessor has nothing to test if those choices live only in someone's head. Close the gap by writing a monitoring scope statement that names each source type (code repositories, social networks, paste sites, job boards and similar), the search terms and the review cadence, then tying it to the system security plan.

Run records missing

Monitoring may happen, but when an assessor asks for proof, the team can only describe it. AU-13 assessments look at monitoring records and system audit records, so each run needs a dated entry showing the sources checked, the queries used, who performed the review and what was found or ruled out. Without that trail, a compliant practice looks identical to no practice. Close the gap by logging every run in a ticketing or case system and retaining those records under the same rules as other audit evidence.

Findings with no owner or notification trail

A leaked credential or internal document found on a public site is only useful if someone is accountable for acting on it. AU-13 requires notifying defined personnel when a disclosure is found and taking defined additional actions, so an unassigned finding is a control failure even when the discovery was correct. Close the gap by naming a finding owner and a backup, defining who must be told and within what internal timeframe, and recording each notification and the action taken, including takedown requests and credential rotation.

Defined frequency nobody follows

Organizations often set a monitoring frequency in policy, then let reviews slip during busy periods or staff changes. Assessors compare what the organization defined with what the records show, so a gap between the written cadence and the logged runs is an immediate finding. Close the gap by assigning the recurring review to a named role, setting calendar reminders or scheduled jobs, and reviewing missed runs at the regular security meeting so lapses are caught and documented rather than silently absorbed.

Tooling set up but never tested

Threat intelligence platforms and log analytics tools can be deployed and connected to feeds without anyone checking that a real disclosure would reach a person. Feeds may be stale, rules may not match the organization's naming, and alerts may go to a channel nobody reads. Close the gap by running a tabletop or controlled test, such as seeding a harmless test marker in a monitored location, and recording whether detection, notification and the defined action all occurred. Open-source options such as MISP, OpenCTI, OpenSearch Security Analytics and Wazuh can each carry part of this workflow, but the test must cover the whole path.

Legal review skipped before collecting personal data

Monitoring public sources can capture personal data about employees, customers or third parties, including profiles, posts and code commits that contain names or contact details. Collecting and storing that material without a documented legal basis, retention limit and access restriction creates a privacy problem of its own. Close the gap by having counsel or the privacy office review the monitoring scope before it starts, limiting collection to what the defined purpose needs, and setting how long monitoring data is kept and who may view it.

AU-13 questions buyers ask before hiring outside help

How much effort does AU-13 take to run?

Effort depends on how many sources the organization monitors, how often it monitors them, and how much triage follows each finding. AU-13 asks for monitoring of defined open-source information and sites at a defined frequency, so the organization must first decide what counts as organizational information (domain names, product code names, executive names, source code fragments, configuration files) and where it might appear, such as social networks, paste sites and public code repositories. The recurring work is reviewing findings, confirming whether a finding is a real disclosure, notifying the people you named, and closing out the case. Ask any provider to show how each of these steps is sized in the written scope before you compare prices.

Can a small security team run AU-13 in-house?

Yes, a small team can run AU-13 in-house if the workload is bounded and someone owns it. The control does not require a particular tool, so a team can start with a short, written source list, a review schedule and a triage procedure that names who decides and who is told. Open-source platforms such as MISP, OpenCTI and Wazuh can hold and correlate findings, but a person still has to read them and act. The harder question is whether the team has time to review findings consistently over the long term. If it does not, the work is a good candidate for a retainer covering review and reporting.

How long does AU-13 setup take?

The setup duration depends on scope, and the written scope sets the timeline. Setup usually covers agreeing the monitored sources and keywords, deciding the review frequency, defining notification and response steps, deploying and configuring the chosen tooling inside your environment, and producing the records an assessor will examine. An organization with a small set of brands and sources can move faster than one with many business units, languages and third-party exposures. Ask for a milestone plan with dependencies, including the time your own staff need to make decisions on triage and actions.

What does the work need from our organization?

The organization owns the control, so it must supply decisions and access that no outside party can make on its behalf. In practice this means:

Named owners for monitoring, triage and notification, with deputies for absences
An agreed source list, including which social networks, code repositories and sites are in scope and any terms that limit monitoring
Access to the systems that will hold findings, such as a self-hosted MISP, OpenCTI or Wazuh deployment inside your cloud account or data center
Decisions on what counts as a disclosure, who is notified, and which actions are taken, such as takedown requests or credential rotation

Without these inputs, the monitoring produces noise and the evidence trail is thin.

Does a monitoring tool alone satisfy AU-13?

No. A tool alone does not satisfy AU-13, because the control asks the organization to monitor for disclosure and to act when a disclosure is found. An assessor will expect a defined monitoring procedure, a stated review frequency, records of what was monitored and reviewed, evidence of notifications to the defined personnel, and records of the additional actions taken. A tool produces some of this evidence, but the policy, the roles and the response decisions must exist as well. Note that SP 800-53B does not select AU-13 for any baseline, so whether it applies depends on your tailoring or overlay decisions.

Can the same AU-13 evidence serve other frameworks?

Some evidence may be reusable, but mappings must be confirmed with the framework owner before you rely on them. NIST's crosswalk from CSF 2.0 to SP 800-53 Release 5.2.0 maps AU-13 to CSF subcategories PR.DS-10 and DE.CM-03, and NIST marks that crosswalk as not comprehensive. No mapping to other frameworks is supplied for this page, so do not assume that an AU-13 record satisfies a control in ISO 27001, SOC 2 or a sector regulation. Ask your auditor or the framework owner which records they will accept, and confirm each mapping in writing before you plan around it.

How DeployOpen scopes and prepares AU-13 evidence

DeployOpen plans, implements and documents the monitoring setup that supports AU-13 Monitoring for information disclosure inside your own infrastructure. The organization owns the control, its monitoring decisions and its response; DeployOpen prepares the systems and evidence for an independent assessor to examine.

How we scope

Agree in writing which open-source sites, feeds and sources the organization will monitor for its own information.
Define monitoring frequency, personnel to notify and response actions, since AU-13 leaves these as organization-defined values.
Confirm whether AU-13 is added through baseline tailoring or an overlay, because no SP 800-53B baseline selects it.

How we build

Deploy self-hosted threat intelligence and detection components, such as MISP, OpenCTI, OpenSearch Security Analytics or Wazuh, within the client's environment.
Configure detection rules and indicators for organizational terms, domains and identifiers, and test that matches generate alerts as defined.
Test the monitoring mechanisms against sample disclosure scenarios and record the results for the assessor.

How we hand over

Document monitoring records, alert routing, tuning decisions and response steps in a form an assessor can examine and trace.
Map the evidence to the three AU-13 determination statements in SP 800-53A and identify any gaps for the client to close.
Deliver configuration, runbooks and test records to the organization, which decides what to submit to its independent assessor.

How we support

Fixed-scope engagements have deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Confirm with your assessor or auditor which evidence formats and review cadence they expect before scope is finalized.