SI-19 De-identification: requirements and evidence

What SI-19 de-identification requires and why the SI-19 de-identification test is the hard part

If your organization shares, tests or retains datasets that contain personally identifiable information, SI-19 requires you to remove defined PII elements from those datasets and to evaluate how effective that removal is at a defined frequency. The control leaves two values to you: which PII elements must be removed, and how often the effectiveness evaluation runs. Both are organization-defined parameters, so an assessor will check that you set them, wrote them down and followed them. A privacy or compliance lead should start by listing the datasets in scope and agreeing on the identifier list before anyone argues about techniques.

SI-19 appears only in the *privacy baseline* defined in SP 800-53B. It is not part of the low, moderate or high security baselines, so a system that is categorized only for security does not inherit it by default. Appendix C of SP 800-53 Rev. 5 marks the control as implemented by both the organization and the system (O/S). In practice, the organization sets the policy, the de-identification standard, the frequency and the ownership of the evaluation, while the system or data pipeline must actually apply the removal and keep the outputs that show it. Confirm with your own privacy office which systems fall under the privacy baseline and whether any contract or regulation extends that scope.

Re-identification testing is usually the hardest part because removing names and account numbers does not prove a dataset is anonymous. Quasi-identifiers such as dates, postal codes, rare job titles or combinations of attributes can still single out a person when joined with outside data. An assessor reviewing SI-19 will look for evidence that the evaluation was designed to test that risk, not only that a script ran. Ask the team that owns the dataset to name the outside data it considers realistic for an attacker, define the measure they will use, and record the result each cycle. Techniques such as statistical disclosure control and differential privacy are enhancements to the control, and none of them is assigned to an SP 800-53B baseline, so decide with your privacy team whether to adopt them voluntarily.

Which datasets, systems and teams fall under SI-19 de-identification

SI-19 applies to the places where personally identifiable information leaves its protected context or gets reused for another purpose. The scope questions below decide which datasets, systems and owners carry the work. SI-19 is assigned only in the SP 800-53B privacy baseline, and FedRAMP's Rev5 baselines do not require it at Class B, C or D.

Datasets leaving the privacy boundary

Start with an inventory of every dataset that moves out of the production environment: analytics extracts, data shared with third parties, research exports and vendor-hosted reporting. Each one needs a documented decision on which PII elements are removed before it leaves. Ask for the data flow records that show where each extract goes and who receives it. Datasets that are never inventoried are the ones most likely to escape de-identification review.

Test and development copies

Production data copied into test, staging or training environments is a common gap. SI-19 expects the identifiers to be removed from the dataset itself, not only restricted by access control in the new environment. Confirm whether refresh jobs, developer snapshots and backups of masked copies are covered by the same procedure. Illustrative example: a masked copy that still carries original timestamps and postal codes may remain re-identifiable.

Systems that hold PII to be stripped

Map the systems where PII is stored and processed, including data warehouses, logs, ticketing exports, backups and spreadsheets used for reporting. Each system that feeds a de-identified output needs a defined list of PII elements to remove. Check the privacy impact assessment and privacy risk assessment documentation, because SI-19 assessors examine those records to confirm the scope.

Third-party data sharing agreements

Where data goes to a partner, researcher or processor, the contract should state which de-identification method applies and who verifies the result. The organization remains accountable for the output it releases. Ask whether the recipient can re-link records using data it already holds, because that determines how much removal is enough. Record these decisions alongside the sharing agreement.

Privacy office and data owners

The privacy office sets which PII elements count as identifiers and approves release decisions. Data owners and system owners implement the removal and keep the records. Security engineering tests whether the output resists re-identification. Assign each decision to a named role in writing so an assessor can trace who approved a dataset and who evaluated the effectiveness of the removal.

Baseline applicability and FedRAMP scope

Confirm the SI-19 requirement against the SP 800-53B baseline that applies to your system. The control is assigned only to the privacy baseline, so a system categorized at low, moderate or high impact without the privacy baseline may not carry it. FedRAMP's Rev5 baselines do not require SI-19 at Class B, C or D, so confirm the exact requirement set in your authorization package before scoping work.

How an assessor tests SI-19 de-identification

This table maps the two SP 800-53A Release 5.2.0 determination statements for SI-19 to examine, interview and test methods, with the evidence an assessor will ask for and the findings that come up most often. Read each row as a question the assessor will put to your team, then confirm that your evidence answers it before the assessment starts.

Assessment element	What the assessor checks	Evidence to prepare	Common finding
Determination statement 1: PII elements	Whether the organization has defined the PII elements to be removed from datasets and the system applies that definition	Documented list of PII elements, the scope of datasets covered, and the owner who approved the list	PII elements never defined, or defined only in general terms such as personal data
Determination statement 2: effectiveness evaluation	Whether de-identification effectiveness is evaluated at the organization-defined frequency and the result is acted on	Evaluation plan, dated test results, re-identification test method, and records of remediation after a failed test	No re-identification test performed, or test run once and never repeated
Examine: system configuration	Whether technical settings for masking, tokenization, generalization or suppression match the documented de-identification approach	Configuration exports, pipeline or transformation job definitions, and change records for those settings	Documented method differs from the configuration actually running in production
Examine: datasets with PII removed	Whether sample outputs contain no defined PII elements and no quasi-identifiers that combine into a re-identifiable record	Sample extracts with the transformation applied, column inventory, and the reviewer's notes	Direct identifiers removed but quasi-identifiers such as dates or postal codes left unchanged
Examine: privacy impact assessment	Whether the PIA identifies the datasets, the purposes for de-identified use and the residual re-identification risk	Current PIA with the de-identified dataset described and risk conclusions traceable to the controls	PIA not updated after the dataset or its intended use changed
Examine: privacy risk assessment	Whether re-identification risk is rated, owned and linked to risk treatment decisions	Privacy risk assessment entries, risk owner sign-off, and treatment or acceptance records	Re-identification risk absent from the register or accepted without a stated rationale
Interview: data owners and privacy staff	Whether people who create and release de-identified data can explain the method and its limits	Interview notes, named roles, and training or procedure references that match what staff describe	Staff unaware of the evaluation schedule or who is authorized to release a dataset
Test: re-identification attempt	Whether a defined test shows the released dataset cannot be linked back to individuals using realistic auxiliary data	Test plan, auxiliary data sources considered, results, and the decision taken on each result	Test not scoped to realistic linkage, or results not recorded

Implementing SI-19 de-identification step by step

The sequence below turns SI-19 from a policy statement into a repeatable process: defined PII elements, a documented method for each dataset, a working transformation pipeline, tested re-identification risk, and results that feed back into privacy risk management. Each step names the artifact it produces so an assessor can trace the control from design to evidence.

Define the PII elements and evaluation frequency
The organization sets the two organization-defined parameters that SI-19 leaves open: which PII elements must be removed from the datasets in scope, and how often the effectiveness of de-identification is evaluated. The privacy office usually owns this decision with the system owner, drawing on the privacy impact assessment for each system. The output is a signed parameter record that names each identifier class, such as direct identifiers and quasi-identifiers, and the review interval. An assessor will test whether these values exist and whether they match what the pipeline actually removes.
Document the de-identification method for each dataset
For every dataset that leaves its authorized purpose, record the technique applied, such as suppression, generalization, pseudonymization or aggregation, and the reason it fits the data's use. The document should also state which fields are kept, which are transformed and the intended recipients. Privacy and data owners review it before any transformation runs. The output is a per-dataset method record that can be traced back to the parameter record from the previous step. Ask your implementation partner or internal team to confirm that every dataset in scope has a record before build work starts.
Build or configure the transformation pipeline
Engineers implement the documented methods in a pipeline that runs on self-hosted infrastructure, with the source data, transformation logic and output store kept inside the organization's own environment. Access to raw identifiers is restricted to the minimum set of service accounts, and transformation parameters are version-controlled so changes are reviewed. Where an open-source data tool performs the transformation, confirm its supported techniques against your method record rather than assuming them. The output is a tested pipeline build, a configuration file under change control and a run log that shows each dataset's transformation.
Run the re-identification and disclosure risk tests
The testing team attempts to link de-identified records back to individuals using the auxiliary data an adversary could realistically obtain, and measures how many quasi-identifier combinations remain unique. Where statistical disclosure control or differential privacy enhancements apply to the dataset, the team checks the protection those techniques claim against the parameters chosen for them. The test is designed to answer the assessor's question directly: can the result be re-identified? The output is a test report listing the attack scenarios, the datasets tested, the residual risk found and any records that failed.
Remediate failures and re-run affected datasets
Any dataset that fails the re-identification test is returned to the method record for revision. The team adjusts the technique, such as generalizing a field further or suppressing a rare combination, then reruns the pipeline and the test on the changed dataset only. Sign-off comes from the privacy function, not the engineers who built the transformation. The output is a remediation log linking each failure to its fix and the retest result, which shows the evaluation led to a change instead of a filed report.
Record results as assessment evidence
The organization assembles the evidence an assessor will examine for SI-19: the parameter record, the method records, the pipeline configuration and run logs, the privacy impact assessment and the test reports with their remediation history. The package is mapped to the two determination statements in SP 800-53A Release 5.2.0 so each claim has a visible artifact. Independent assessors, not the implementation partner, decide whether the evidence meets the control. The output is an evidence folder indexed by control and dated against the evaluation cycle.
Feed findings into the privacy risk assessment
Residual re-identification risk, recurring failures and changes in the datasets feed back into the privacy risk assessment and the related privacy controls the catalog links to SI-19, including RA-2 and PM-22. Where a finding shows that a dataset's purpose or recipients have changed, the privacy impact assessment is updated before the next release. The output is an updated risk register entry and, where needed, a revised privacy impact assessment. This closing step is what keeps SI-19 an ongoing evaluation rather than a one-time exercise.

How re-identification testing and disclosure control work in practice

Removing direct identifiers is the starting point, not the finish line. Names, account numbers and national identifiers are easy to strip, but SI-19 asks the organization to remove the defined PII elements and then evaluate whether the result still exposes individuals. The gap is usually quasi-identifiers: fields such as postal code, birth date, job title, admission date or device type that look harmless alone. Combined with another dataset that is public or already held by an attacker, they can single out a person. Re-identification testing means trying that linkage on purpose, using the outside data an adversary could realistically obtain, and recording which records can still be matched. The privacy team should decide who owns that test, which datasets are in scope and what result would trigger a rework of the release.

The SI-19 enhancements address the techniques that go beyond removing fields. The supplied control information places statistical disclosure control and differential privacy in this area, and these are the mechanisms an organization uses when suppressing, generalizing or perturbing values is not enough to protect small groups or repeated queries. Because SP 800-53B assigns none of the enhancements to a security baseline, the organization should confirm with its privacy and legal owners which enhancements its program adopts, and document why any it sets aside are not needed for the datasets it releases. Check the current enhancement text in the NIST catalog before writing that decision down, since the wording is authoritative only in the published control.

Two practical checks follow from this. First, record the defined parameters, such as the elements treated as PII and the evaluation frequency, in the system's privacy documentation so an assessor can compare the stated approach with the dataset actually released. Second, keep the evidence that the test was run: the method, the outside sources assumed, the results and the follow-up decisions. Assessors typically look for a privacy impact assessment or privacy risk assessment that matches the data release, and an approach that changes when the data or the threat changes. An implementation partner can help build the test harness and documentation, but the organization owns the risk decision and any independent assessment remains with an assessor.

Evidence that passes an SI-19 de-identification review

An assessor testing SI-19 looks for proof that PII elements were removed from specific datasets and that the organization tested whether the result can still be re-identified. The cards below cover the records that make that proof, and each one needs a refresh cycle tied to the evaluation frequency the organization defined.

Defined PII element list

This is the organization's list of the personally identifiable information elements it removes from datasets, with the reason each element is in scope. SI-19 requires the removal of defined elements, so the list is the baseline every other artifact is measured against. Check that it matches the data inventory, that quasi-identifiers such as dates, postal codes and job titles are addressed, and that the owner signs off on each revision. Review it whenever a new data source is onboarded.

Per-dataset de-identification procedures

Each dataset released or shared without identifiers needs its own written procedure stating the source, the elements removed, the method applied and the intended recipient. A single generic procedure rarely shows that the specific transformations fit the specific data. Assessors often sample one dataset and ask for its procedure, so keep these records indexed by dataset name.

Transformation configuration and logs

Configuration files, scripts or pipeline definitions show exactly how identifiers were suppressed, generalized or masked, and logs show that a given run applied them. Store the configuration under version control so the state at any past release can be reproduced. Confirm that logs record the input version, the output version and the operator, without copying the raw identifiers into the log itself.

Re-identification test reports

These reports record how the team tested whether a de-identified dataset can be linked back to individuals, including the attacker assumptions, the auxiliary data used and the result. SI-19 asks the organization to evaluate effectiveness at its defined frequency, so each report should name the date, the dataset version and the tester. Re-run the test whenever the dataset, the method or the external data landscape changes.

Privacy impact and risk assessment entries

Entries in the privacy impact assessment and privacy risk assessment record why a dataset is shared, which risks remain after de-identification and how they are accepted or treated. These documents are related controls for SI-19, and assessors compare them against the datasets they actually see. Keep the entries dated and link each one to the dataset and the re-identification report it relies on.

Sign-off and review records

Sign-off records show that the data owner, privacy function and, where the procedure requires it, the recipient approved each release, and that the periodic evaluation was completed on schedule. Missing or undated approvals are a common finding because they break the chain from policy to dataset. Assign each review to a named role and retain the signed record for the period the organization defined.

What meeting SI-19 de-identification costs

This table breaks down the effort behind SI-19 de-identification by cost component, showing who is paid, whether the cost is one-time or recurring, and what drives it up. Use it to shape a written scope before asking for a quote, since most of the spend depends on how many datasets are released and how often. No prices or durations are given because none are supplied for this control.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it
Privacy and legal review	Privacy office, counsel, or an outside privacy advisor	One-time per dataset type, then recurring at each review	Number of distinct datasets, sensitivity of PII elements, and new recipients
Engineering to build pipelines	Internal data engineers or an implementation partner	One-time build, then recurring maintenance	Number of source systems, schema complexity, and whether removal is automated
Re-identification testing	Internal testers or an external tester under written scope	Recurring, tied to each release of a dataset	Quasi-identifier count, dataset size, and whether linkage data is available to attackers
Statistical disclosure control and differential privacy setup	Data scientists or an implementation partner	One-time design, recurring tuning	Whether enhancements beyond basic removal are selected and how many queries the data serves
Evidence upkeep	Compliance lead and system owners	Recurring	Frequency of de-identification evaluations and number of systems in the privacy assessment
Assessor sampling	Independent assessor, as part of the audit fee	Recurring at each assessment cycle	Number of datasets selected for examination and completeness of the records kept
Open-source tooling	Internal staff or an implementation partner for setup	Setup one-time, hosting recurring within the client's own infrastructure	Choice of self-hosted tools can reduce license spend, but staff time for configuration and testing remains

Who owns SI-19 de-identification and what partners usually take on

Your privacy and data team owns the decisions that define what de-identification means for your data. SI-19 asks the organization to remove defined elements of personally identifiable information and to evaluate how well that removal works at a frequency the organization sets, so the parameters are a policy choice, not an engineering default. The team decides which identifiers and quasi-identifiers are in scope, which datasets the control covers, how often effectiveness is evaluated, and what residual re-identification risk is acceptable. It also documents those decisions in the privacy impact assessment and privacy risk assessment, which are among the objects an assessor will examine.

Element selection: Defining which PII elements must be removed for each dataset and purpose.
Evaluation frequency: Setting the organization-defined interval for re-checking de-identification effectiveness.
Risk acceptance: Recording who accepts residual re-identification risk and on what basis.
Data-sharing terms: Aligning de-identified outputs with contracts and internal use rules.
Documentation: Keeping the privacy impact and risk assessments current with each dataset change.

Before any engagement starts, confirm that these decisions are written down and that a named owner can defend them to an assessor.

Gaps that cause SI-19 de-identification findings and how to close them

SI-19 is a privacy baseline control, so assessors look at whether the de-identification step is defined, applied everywhere data flows, and tested for re-identification. The gaps below recur across assessments and each one has a concrete fix the organization can verify before an assessor arrives.

Undefined organization-defined parameters

SI-19 has 2 organization-defined parameters, and an assessor cannot test the control until the organization has stated which PII elements must be removed and how often de-identification effectiveness is evaluated. Many programs leave these blank in the system security and privacy plan. Fix this by writing both values into the plan, tying the element list to the data inventory, and confirming that the evaluation frequency matches what the team actually does.

De-identification applied to one copy only

Teams often strip identifiers from the extract that goes to analytics but leave the same fields in backups, replicas, exports, logs or derived tables. The assessor examines datasets with PII removed, so every copy that leaves the protected store must be checked. Fix this by mapping data lineage from the source to each derived dataset and confirming that the removal step runs on every path, not just the first.

No re-identification test

Removing direct identifiers does not show that the remaining fields cannot be linked back to a person. SI-19 requires evaluating the effectiveness of de-identification, and a missing test is a common finding. Fix this by running a documented linkage or uniqueness test against an outside reference dataset, recording the method, the result and the reviewer, and retaining that record as evidence.

Evaluation frequency not followed

The organization may define a re-evaluation cycle and then miss it because no owner is assigned or the work is not on a calendar. Assessors compare the stated frequency with the dated evidence. Fix this by assigning a named owner, scheduling each evaluation in the same tracker used for other privacy tasks, and keeping dated outputs so the cycle is visible.

Privacy impact assessment not updated

When a dataset, purpose or recipient changes, the privacy impact assessment and privacy risk assessment documentation should reflect the new de-identification approach. Assessors examine this documentation alongside the datasets. Fix this by adding a trigger to the change process so any new data flow or de-identification change requires a PIA review before release, and by recording the review date in the PIA.

Test data copied from production without stripping

Developers and testers frequently receive full copies of production databases, which can carry PII into lower environments with weaker access controls. This undermines any de-identification done for analytics. Fix this by making de-identified or synthetic data the only permitted source for non-production environments, enforcing that rule in the refresh pipeline, and checking a sample of refreshed test data for identifiers before each release.

Questions buyers ask about SI-19 de-identification

Is SI-19 de-identification required outside the privacy baseline?

No. SP 800-53B assigns SI-19 only to the privacy baseline, not to the low, moderate or high security baselines. An organization that runs a moderate system for security purposes does not inherit SI-19 from that selection alone. It becomes a requirement when the system's privacy baseline applies, when a contract or regulator adopts that baseline, or when the organization chooses to apply it as a risk decision. Confirm the selected baseline and any overlays with your authorizing official or contracting officer before scoping work, because the answer depends on which profile your system and its agreements actually use.

What does SI-19 actually ask an organization to do?

SI-19 asks the organization and the system to remove defined elements of personally identifiable information from datasets and to evaluate how well that removal works at a defined frequency. The control has 2 organization-defined parameters that you must set, such as which PII elements are removed and how often effectiveness is evaluated. The eight enhancements cover techniques such as statistical disclosure control and differential privacy, but none of them is assigned to an SP 800-53B baseline. In practice, the work is a documented de-identification method, a repeatable test that the output cannot be re-identified, and records showing that the test ran on schedule.

How much effort does SI-19 de-identification take?

Effort depends on the number and type of datasets, the sensitivity of the PII elements, and how many reuse paths exist for the output. No public figure in this context gives a duration or fee, so ask for one in writing. The main cost drivers are: the number of datasets in scope, whether the data is structured or free text, whether the output is released internally or to third parties, and how many re-identification tests the privacy team requires. One-time work includes defining parameters, building the transformation and writing the test plan. Recurring work includes rerunning evaluations, reviewing results after data changes and keeping evidence current.

What does the privacy team need to provide for SI-19?

The privacy team owns the decisions that the control cannot automate. It needs to define which PII elements count as identifiers for each dataset, set the acceptable re-identification risk, approve the de-identification method and decide how often effectiveness is evaluated. It also needs to connect SI-19 to the privacy impact assessment and privacy risk assessment documentation, which SP 800-53A lists among the examine objects. Ask your privacy office to commit to those decisions in writing before engineers start building transformations, because a technical team cannot set an acceptable risk threshold on its own.

Can we implement SI-19 de-identification in-house?

Often yes, if you have data engineers who can write and test transformations and a privacy function that can make the risk decisions. The control itself is an organizational responsibility, so an in-house team can own it fully. Outside help is most useful for preparing the datasets, building repeatable pipelines, writing the re-identification tests and assembling the evidence package. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own environment and prepares systems and evidence for compliance assessments. It does not issue assessment results, and an independent assessor still decides whether the control passes.

How does FedRAMP Rev5 treat SI-19?

FedRAMP's Rev5 baselines do not require SI-19 at Class B, C or D, according to the consolidated rules for 2026. A cloud service offering pursuing those classes does not need to add SI-19 to its control set for that reason. That does not remove privacy obligations under other laws or contracts, so confirm with your FedRAMP authorizing official and your privacy counsel whether any agreement or data type brings the control back into scope. Check the current FedRAMP control reference before you finalize your control matrix, since FedRAMP updates its content.

How do we test that de-identified data cannot be re-identified?

Start by defining the threat: who might attempt re-identification, what outside data they could combine with the dataset, and what harm would follow. Then run a test that matches that threat, such as checking for unique combinations of quasi-identifiers, measuring the effect of removing or generalizing them, or testing whether records can be linked to a reference source. Statistical disclosure control and differential privacy are the enhancement families to consider when simple removal leaves residual risk. Record each test's inputs, method, result and reviewer. An assessor will look for the examine evidence and for proof that the evaluation happened at the frequency you defined.

Which related controls should we review alongside SI-19?

The Release 5.2.0 catalog links SI-19 to six related controls: MP-6, PM-22, PM-23, PM-24, RA-2 and SI-12. MP-6 covers media sanitization, which matters when de-identified copies are stored or moved. SI-12 covers information retention and minimizing PII in testing, which overlaps with de-identified test data. RA-2 covers security categorization and risk assessment, which feeds the re-identification risk decision. The PM controls cover organization-wide privacy programs, including the privacy program plan and policies. Review these together so your evidence for one control does not contradict another.

Where to confirm the current SI-19 text and baseline assignment

Before you scope SI-19 for a dataset, confirm its wording and baseline status against the current NIST release, not against a summary or an older copy. The authoritative machine-readable source is the Release 5.2.0 catalog in NIST's OSCAL content, which holds the SI-19 text, its two organization-defined parameters and its eight enhancements. The same repository publishes the SP 800-53B profiles, so you can check directly that SI-19 appears in the privacy baseline and not in the low, moderate or high profiles. Pull the SP 800-53A Release 5.2.0 assessment procedures from the same content set to see the two determination statements and the examine objects your assessor will use, such as the de-identified datasets and the privacy impact assessment documentation. Start from the SP 800-53 Rev. 5 publication page and the SP 800-53B publication page to confirm which release each document represents.

Next, check the FedRAMP reference for the Rev5 baselines, because it is the one place where SI-19 may be excluded for a cloud service. The FedRAMP Rev5 System and Information Integrity reference states the current baseline treatment for the SI family, and the Consolidated Rules for 2026 should be read alongside it before you rely on the Class B, C or D position in your authorization package. Record the release number, the date you accessed each source and the file you used in your evidence folder, since NIST issues changes as numbered releases and the OSCAL content is versioned separately. Ask your assessor or authorizing official which version they will test against. If the text or baseline assignment differs between your sources, the controlling document for your authorization or contract decides the question, and your compliance lead should document that choice in the system security and privacy plan.

How DeployOpen scopes and prepares SI-19 de-identification evidence

DeployOpen works on SI-19 De-identification as a fixed-scope implementation and testing engagement inside your own infrastructure. We prepare the datasets, de-identification workflows, test records and documentation that an independent assessor would examine, while your organization keeps ownership of the control and the privacy decisions behind it.

How we scope

Confirm which systems and datasets fall under the privacy baseline and need de-identification handling
Record the PII elements to be removed and the defined evaluation frequency in the written scope
Agree which enhancements, if any, are in scope, such as statistical disclosure control or differential privacy testing

How we build

Configure self-hosted open-source pipelines that remove defined identifiers from copies of datasets inside your environment
Run re-identification tests against de-identified outputs and log results for each evaluation cycle
Integrate configuration and job logs so the system state can be examined alongside the de-identified data

How we hand over

Deliver the configuration, test scripts, results and runbooks needed to repeat the de-identification evaluation
Map each deliverable to the SI-19 determination statements and examine objects in SP 800-53A for your assessor
Document residual re-identification risk and open items for your privacy and risk owners to accept or act on

How we support

Support re-runs of de-identification tests after schema or data source changes, as set out in the written scope
Offer ongoing support, upgrades and continuous testing as a retainer if your evaluation cycle needs it
Confirm with your assessor which evidence they accept, since DeployOpen prepares evidence but does not issue assessment reports