SI-20 Tainting: requirements and evidence

What SI-20 tainting asks for and why most systems never select it

If SI-20 appears in your tailoring worksheet or a customer questionnaire, the short answer is this: SI-20 asks you to embed data or capabilities in defined systems or components so you can tell whether your organizational data has been exfiltrated or improperly removed. No SP 800-53B baseline selects it, so it arrives in your program only because you chose it through tailoring or an overlay. In Appendix C of SP 800-53 Rev. 5 it is marked as implemented by the organization and the system and as an assurance-related control, which means the detection capability itself is the thing an assessor will want to see working.

The control is short. It has one organization-defined parameter, which is the set of systems or components where the markers are placed, and it has no control enhancements in Release 5.2.0. That brevity is misleading. The parameter forces you to decide where markers go, and each placement is a design decision with consequences. A marker in a document store, a database record, a file share or an API response can be copied, exported or logged by normal business use, so you have to decide which copies are expected, which are suspicious, and who owns the response. Markers that trigger on legitimate processing create alert fatigue, while markers that are too subtle never fire. Markers can also break downstream parsers, reports or integrations if they are inserted into live data without care.

The harder question is proof. An assessor testing SI-20 against SP 800-53A will examine system design documentation and system configuration settings, and the one determination statement asks whether the tainting mechanism is in place. Before your first assessment, confirm three things in your own environment: which components carry markers, that a planted marker produces an alert in the monitoring pipeline, and that someone is assigned to act on it. A marker that no one can show being detected is documentation, not a control.

Which systems and data justify selecting SI-20

SI-20 is not in any SP 800-53B baseline, so it enters a system only when the system owner and risk owner select it through tailoring or an overlay. The cards below cover the scoping questions that decide whether the control is worth the work, and which systems and data stores it would touch.

Which data classes warrant markers

Start with the data whose exfiltration would matter most, such as regulated personal data, proprietary designs or credentials. SI-20 requires embedding data or capabilities in defined components so that unauthorized copies can be detected, so a broad marking scheme across every data class multiplies the design and testing effort. Ask the risk owner to name the classes in writing, because the organization-defined parameter for SI-20 depends on that list.

Which repositories and file stores hold them

Map every repository, file share, document store and export location that holds the selected data classes. Marked data that lives in places the team does not inventory cannot be traced when it leaves. The inventory also shows where the system design documentation and configuration settings examined under SI-20 must come from.

Which databases and cloud buckets are in scope

Databases, object storage buckets and data lakes are common exfiltration paths because bulk export is easy. Decide whether markers go into records, fields, file metadata or dedicated canary objects, since each choice changes how the marker is generated and how often it must be verified. Confirm with the platform team which storage services support the chosen approach before committing to it.

Whether third parties receive copies

If a processor, support vendor, backup service or partner holds copies of the marked data, the detection path extends beyond your own boundary. Identify each external recipient and decide whether a marker can reach their environment, and whether their contracts allow monitoring for marked outputs. Where copies leave your control, the decision should be recorded with the risk owner, not left to the engineering team.

Which outside hosts can receive exports

Consider the destinations that data could reach without authorization, such as unmanaged endpoints, personal cloud accounts, public code repositories and outbound network paths. Each destination class changes whether a marker can be detected at the point of egress, and which monitoring tools must see it. Document which destinations are blocked, which are monitored and which are accepted as residual risk.

Who owns the selection decision

The system owner and risk owner decide whether SI-20 is selected, because it is not required at FedRAMP Rev5 Classes B, C or D and is not in any SP 800-53B baseline. Confirm with the compliance lead whether the authorizing framework, contract or overlay requires it at all, and record the rationale in the system security and privacy plan. A decision that rests only on engineering preference is hard to defend at assessment.

How an assessor tests SI-20 and what they request

This table walks through how an assessor works through the single SP 800-53A determination statement for SI-20, row by row, from the design documents and configuration records to interviews and tests. Read each row as a request the assessor will make, then check whether your environment can answer it with evidence. The main takeaway is that the assessor is looking for a traceable chain from each marker to a named owner and a working detection.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine: system design documentation	Reads the design documents to see whether the organization has defined where markers are embedded, which systems carry them and how a marker hit is meant to reach people who act on it.	Architecture diagrams showing marked data stores or components, a marker register, and the design decision that ties markers to detection.	Markers described in a policy but absent from the design, or design documents that name no detection path.
Examine: system configuration settings and associated documentation	Checks the live or exported configuration to confirm that the markers exist as described and that their monitoring hooks are set up.	Configuration exports or screenshots showing marker records, the monitored location, alert rules and the related change records.	Markers configured in one environment but not production, or settings changed without updated documentation.
Interview: system owners and security operations staff	Asks who owns each marker, who receives its alerts and what the responder does on a hit, and compares the answers with the documents.	Named owners on the marker register, on-call or escalation records, and a short runbook for marker alerts.	Owners who cannot be named, or responders who did not know markers existed.
Test: marker trigger to detection	Requests a controlled trigger of a marker, or reviews a past trigger, and follows it to see whether it appears as an alert in the monitoring system.	Records of a trigger event, the resulting alert or log entry, and the ticket or case opened from it.	Markers that fire silently, alerts that are dropped by a filter, or no test record at all.
Test: detection exercised over time	Looks for evidence that the detection has been run on a repeatable schedule and that results were reviewed, not only set up once.	Dated test or exercise records, review sign-offs and any changes made after a test.	Detections never exercised since they were configured, or tests run once and never repeated.
Interview and test: removal of marker data	Asks how markers are handled when data is retired or moved, and whether an improper removal would still raise an alert.	Procedure for retiring marked data, and records showing the marker was tracked through the change.	No link between marker lifecycle and the change process, so markers are lost during migrations.
Examine: link between marker and monitoring system	Traces one marker through to the monitoring platform to confirm the connection is documented and maintained.	Data flow or integration diagram from the marked component to the log or alert platform, with the rule that matches it.	No documented link between the marker and the monitoring system, or a link that depends on one person's setup.

Implementing SI-20 in five steps

This sequence takes SI-20 from an optional selection decision to a tested, reviewed detection path, with each step leaving a record an assessor can examine. Because the control is not in any SP 800-53B baseline, the first step is to confirm the organization actually selected it.

Confirm selection and set the organization-defined parameter
The system owner, security lead and authorizing official confirm that SI-20 is in scope through tailoring or an overlay, since no SP 800-53B baseline assigns it. They then set the single organization-defined parameter, which names the systems or components where embedded markers will be placed. The output is a signed parameter record that cites the tailoring decision, so an assessor can trace why the control applies and where it is bounded. Confirm with your authorizing body whether any overlay you rely on already sets this value.
Define data classes and components that receive markers
Working with data owners, identify which data classes are worth tagging, such as customer records, credentials-adjacent exports or internal reports, and which repositories, file shares, databases or applications hold them. Mark the boundary of each class so that the tagging scope matches the parameter set in the previous step. The output is a scoping table that lists each data class, its system of record and the owner who approved it. Review it with the data owners before any marker is created.
Design and register marker types and storage locations
The security engineering team designs the marker types, for example canary records, unique identifiers embedded in documents, or callback-capable files, and documents where each one is stored and how it reports. Each marker must be unique, traceable to one location and kept out of production logic. The output is a marker register that records marker ID, data class, host system, creation date and owner, reviewed and approved by the control owner. Store the register under configuration management so changes leave a history.
Connect marker detection to log collection and alerting
Engineers route the events that markers produce into the log pipeline and write a detection rule that fires when a marker is observed outside its expected context. Open-source options such as Wazuh, OpenSearch Security Analytics with Sigma rules, or Suricata EVE JSON output for network-level callbacks can carry these events, but you should confirm each platform's parsing and correlation support for your marker format in your own environment. The output is a detection rule with recorded test results showing a planted marker triggering an alert to the responsible queue.
Test, document and review the detection path on a schedule
Run controlled exfiltration tests with known markers at a frequency the organization sets in its own control procedures, and record whether each alert fired, reached the right responder and led to a documented response. Retire or rotate markers that have been exposed, and update the register when data classes or systems change. The output is a test record and a periodic review record signed by the control owner, which together form the evidence an independent assessor would examine. Specify the review interval in your own documentation rather than relying on a generic figure.

Evidence that passes an SI-20 assessment

SI-20 is assessed largely by examining design documentation and configuration settings, so the evidence is a set of records that connect one another: what the organization chose to mark, where the markers live, what detects them, and whether the detection was tested. Each card below is one artifact, with a note on how to keep it current between assessments. The assessor decides whether the set is sufficient.

Documented parameter and selection rationale

SI-20 has one organization-defined parameter, so the organization must state which systems or components carry markers and why those were chosen. The rationale should tie the choice to data that matters, such as regulated records, source code or credential stores, and name the systems that were considered and excluded. Keep the document in the system security plan or its tailoring record. Review it whenever a system holding sensitive data is added, moved or retired, and record the review date. The assessor decides whether the selection is sufficient for the stated risk.

Marker register

The register lists every embedded marker: its identifier, the file, record or capability it sits in, the host or component that holds it, its owner and the detection rule it feeds. Without a register, nobody can tell whether a missing alert means a marker was never triggered or was removed. Treat the register as a controlled record that changes only through the change process. Reconcile it against the actual deployments each quarter, or after any system change, so that the assessor sees an accurate inventory rather than a list written for the audit.

Configuration of components holding markers

Capture the configuration of each system that stores or serves markers, including the settings that control how markers are placed and who can read or alter them. Export the relevant configuration files and keep a dated copy alongside the baseline it was checked against. Confirm that marker-bearing data is not excluded from logging or replication without a recorded decision. Re-export after every configuration change so the evidence matches the running state. Ask your platform team to confirm which settings the assessor is likely to request before the assessment window opens.

Detection rule and alert routing

Show the rule that matches a marker trigger and the path the resulting alert takes to a responder. In a self-hosted stack this might be a Sigma-style rule in OpenSearch Security Analytics, a custom rule in Wazuh, or a Suricata EVE JSON record forwarded to a log platform. Document the rule text, its severity, the log source it reads and the notification channel. Review the rule when log formats change, because a parser update can silently stop matches. Note who receives the alert and what the escalation path is.

Test records of marker triggers

A marker that has never fired in a test cannot be shown to work. Keep dated test records in which a controlled copy of a marker was accessed or moved outside its permitted path, and the resulting alert is captured with its timestamp, rule identifier and recipient. Run the test after each detection rule change and at a cadence the organization sets and documents. Record failed tests and the fix that followed, since assessors often value that trail. Any test data should be clearly labeled as test data so it is not mistaken for a real incident.

Review log of the marker set

The review log proves that the marker set is kept current. Each entry records the reviewer, the date, the systems reviewed, the changes made to the register and the reason, such as a new data store or a retired application. Tie entries to system change records so the link between a change and its marker update is visible. Set a review cadence that matches how often the environment changes, and add an unscheduled review after significant changes. Ask the assessor early whether they expect the log to cover a fixed period.

What meeting SI-20 costs in money and effort

This table breaks the cost of meeting SI-20 Tainting into its components, showing who is paid, whether each cost is one-time or recurring, what moves it, and what to request in a quote. NIST does not estimate compliance costs and no supplied figure sets a price, so use the table to structure your own estimate and quote requests. The main takeaway is that open-source monitoring can remove license spend, but marker design, engineering and review effort remain.

Cost component	Who is paid and one-time or recurring	What drives it up or down	What to request in a quote
Marker design and register	Internal architects or an implementation partner. One-time, with periodic revision.	Number of defined systems and components, and how many distinct data types need markers. A narrow scope keeps this down.	A written list of defined components, marker types, and the register format that assessors will review.
Engineering to embed and maintain markers	Internal engineers or a partner. Initial build is one-time; upkeep is recurring.	Platform diversity, the number of data stores, and how often schemas and applications change. Standard patterns reduce rework.	Named deliverables per component, a change procedure for new markers, and who fixes markers after upgrades.
Log and alert integration	Internal platform or security engineers. One-time build, recurring tuning.	Volume of events from marker hits, how many log sources feed the monitoring platform, and alert routing rules.	Confirmed log sources, parsing and field mapping, and the alert path to the responsible team.
Monitoring license or hosting spend	Software vendor or cloud provider. Recurring.	Licensing model and data ingestion volume. Self-hosted open-source options such as OpenSearch, Wazuh and Suricata can remove license fees but still need compute and storage.	Itemized licensing or hosting terms, storage retention assumptions, and any support subscription separate from the software.
Detection testing	Internal testers or a partner. Recurring, usually tied to change cycles.	Number of markers, environments tested, and whether test exfiltration paths are simulated end to end.	A test plan showing which markers are triggered, how alerts are verified, and the evidence each test produces.
External testing or review	Independent testers or reviewers, engaged by the organization. Periodic.	Scope of the review, how many systems are covered, and whether the design or only the operation is examined.	A written scope, deliverables, and whether the reviewer issues a report. Confirm that it is not the auditor issuing the assessment.
Auditor sampling time	The organization's independent auditor or assessor. Recurring with each assessment cycle.	Number of markers, the quality of the register and test records, and how quickly evidence can be produced.	Ask the auditor how they sample marker evidence and what records they expect for each sample.

Which open-source tools can detect tainted data leaving the boundary

Four open-source components can record the network and host events that would show a tainting marker leaving the boundary, but none of them creates the marker. The organization defines the marker, decides where it is embedded, and writes the matching rule, and these tools then turn matches into findings or alerts that can be reviewed and retained.

OpenSearch Security Analytics

Security Analytics runs detectors against ingested logs from hosts, network devices and cloud services, matching them against prepackaged or custom Sigma rules. A rule written for a marker string, a canary identifier or a tagged file name can record each match as a finding with its rule, log type and severity, and send an alert to Slack or email. Check that the logs carrying the marker, such as proxy, DNS or cloud egress logs, are actually ingested, and confirm the license terms (Apache-2.0) fit your deployment.

Wazuh alert pipeline

Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus any custom rules you add. Matching alerts are written to alerts.log and alerts.json, mapped to MITRE ATT&CK and forwarded to the Wazuh indexer for review. A custom rule can flag a marker value in endpoint or application logs, but it only sees what agents collect, so confirm coverage on the hosts that hold tagged data. Wazuh is licensed under GPL-2.0-only, which should be reviewed by counsel if you modify and redistribute it.

OPNsense intrusion detection

OPNsense includes an intrusion detection and prevention system built on Suricata, using rulesets such as Emerging Threats and Abuse.ch. It can alert on or block matching traffic at the network boundary, and it can send alerts to syslog in EVE JSON format. This is the place to watch for outbound transfers that carry a known marker pattern, provided the marker is visible in clear traffic. Encrypted traffic will hide most markers, so decide whether TLS inspection is in scope. The OPNsense license is BSD-2-Clause.

Suricata EVE JSON output

Suricata's EVE output writes JSON records for alerts, flows, and protocol transactions including HTTP, DNS, TLS, SSH and SMB, plus file information and engine statistics. These records can be split into separate files for a log management tool, so a flow record showing a large outbound transfer can be correlated with a marker alert. The EVE output shows what left the network, not whether a marker was present in content you did not inspect. Suricata is licensed under GPL-2.0-only, so confirm the terms that apply to your build and distribution.

Who owns, implements and assesses SI-20

The organization owns SI-20 in full. Because SP 800-53B does not assign SI-20 to any baseline, the first decision is whether it belongs in the organization's selected control set at all, through tailoring or an overlay. That decision, the value chosen for the single organization-defined parameter, and any risk acceptance for systems where tainting is not used must be recorded by the people accountable for the authorization or the program. The organization also keeps operational responsibility: someone must review alerts raised by markers and decide what happens next.

Selection decision: Record why SI-20 is or is not selected, referencing the system's impact level, data types and threat model, and the tailoring or overlay that drives the choice.
Parameter value: Define the systems or components where data or capabilities are embedded, since that is the single parameter SI-20 leaves to the organization.
Risk acceptance: Document who accepts the residual risk where tainting is not deployed, and set a review date.
Operational ownership: Name the team that receives marker alerts, triages them and escalates to incident response.
Policy alignment: Confirm that the SI-1 policy and procedures and the audit and monitoring controls reference how marker events flow.

Before engaging anyone, confirm the selection decision and parameter are signed off, because every later tab depends on them.

Where SI-20 programs usually fall short

SI-20 Tainting works only when the organization decides why it needs markers, who owns them, and how a triggered marker reaches someone who acts on it. The gaps below tend to appear in that chain, from the initial selection of the control through to the marker register that records what was placed and where.

Selecting the control without a rationale

SI-20 is not assigned to any SP 800-53B baseline, so it enters a system only through tailoring or an overlay. Programs often add it because it sounds protective, with no record of the threat it addresses. Write a short risk rationale that names the data at risk and the exfiltration path being detected, and record the decision in the system security and privacy plan so an assessor can trace why the organization selected SI-20.

Markers placed without an owner

A canary record or tracking token in a dataset is useful only if someone is accountable for its placement, rotation and response. When the team that seeded the data leaves, nobody knows the marker exists. Assign a named owner for each marker class, state who may approve a new marker, and confirm that the owner can answer an assessor's questions about it.

Detection rules that were never tested

A rule that matches marker activity may never fire because the log source is missing, the field name changed or the event type is filtered out. Test each detection by triggering the marker in a non-production copy and confirming a finding appears in the SIEM with the expected rule and severity. Keep the test result as evidence for the SI-20 assessment, since examiners look for configuration and design documentation that shows detection works.

Alerts routed to an unmonitored mailbox

Marker alerts sent to a shared mailbox that nobody watches are the same as no alert. Route them to an on-call queue or case management system with an escalation path and a response time that the incident response team has agreed. Review the routing whenever staff or channels change, and record who received each alert during the test period.

Markers that break applications or privacy duties

A marker embedded in a field that an application parses, or a token that carries personal data, can cause errors or create a new privacy obligation. Before deployment, check each marker against application tests and the organization's data inventory, and confirm with privacy staff that the marker content does not itself identify individuals. Document the decision so the marker's design can be reviewed alongside the privacy controls.

Marker register that drifts after changes

Migrations, schema changes and new data flows can move or copy markers without anyone updating the register. The register then shows markers that no longer exist and omits ones that do. Tie register updates to the change management process, reconcile the register against the data stores on a defined schedule, and retain each reconciliation as evidence of ongoing operation.

Questions buyers ask about SI-20 before hiring help

Is SI-20 harder to implement than other SI controls?

SI-20 is usually narrower in scope than the monitoring and integrity controls around it, but it is less familiar, so the design work takes more judgment. The control has one organization-defined parameter and no enhancements, and SP 800-53A Release 5.2.0 assesses it through a single determination statement. Compare that with SI-4 System monitoring, which has many enhancements and sensor placement decisions across the environment. The effort for SI-20 concentrates on deciding which data is worth marking, where the markers are embedded, and how a triggered marker reaches the people who respond. Those decisions depend on your data classification and architecture, not on the size of the control text.

Does any SP 800-53B baseline require SI-20?

No. SP 800-53B does not assign SI-20 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Appendix C of SP 800-53 Rev. 5 lists it as implemented by the organization and the system and marks it as an assurance-related control. FedRAMP's Rev5 baselines do not require it at Class B, C or D. Confirm the requirement against your contract, customer questionnaire or sector regulator before assuming it is out of scope, because a specific agreement can still ask for it.

How long does SI-20 setup take, and what sets the timing?

The timing depends on the number of data stores in scope, how many systems can carry markers, and how many teams must approve the design. No duration is set by NIST or by any baseline for SI-20, so treat any figure you are quoted as a project estimate tied to a written scope. The main drivers are the data classification work that comes first, the number of environments (production, test, backup, analytics), whether markers must be tested without disrupting users, and how long monitoring rules take to validate. Ask a provider to break the timeline into discovery, design, build, test and handover, and to name which of those steps depend on your approvals.

What does SI-20 need from our engineers and security staff?

The work needs both data owners and platform engineers. Data owners identify which datasets justify marking and what a credible exfiltration signal looks like for each one. Platform engineers decide where markers sit, such as in document templates, database records, test datasets or file shares, and how they are generated and rotated. Security staff own the detection path: which logs or alerts show a marker leaving its boundary, who triages the alert and what response follows. Plan for part of the time of these people during design and testing, and for ongoing ownership once the markers are live.

Can we implement SI-20 in-house without outside help?

Yes, many organizations can build SI-20 with their own staff, provided they have people who understand the data, the systems and the detection tooling. The control is less about specialist software and more about deliberate design and clear ownership. Outside help is most useful when the team lacks experience designing markers that will not break applications, when the scope spans several self-hosted platforms, or when the design must be documented well enough for an assessor to test it. An implementation partner can prepare the systems and evidence, but the organization still owns the control and decides what is marked.

Will an auditor accept markers we built ourselves?

An auditor can accept self-built markers if you can show the design, the configuration and evidence that the mechanism works. SP 800-53A Release 5.2.0 examines system design documentation and system configuration settings with associated documentation, so an assessor will want to see where the markers are defined, how they are embedded, and how a test event produces a detection. Keep records of the marker design, the rules that match them, test results, and the alert handling procedure. Only an independent auditor or assessor decides whether the control is satisfied, so confirm the assessment expectations with that party before the build starts.

Which open-source tools can detect a triggered SI-20 marker?

Several self-hosted tools can receive and alert on marker events, and the right choice depends on where your logs already go. OpenSearch Security Analytics runs detectors against ingested logs, using Sigma rules, records matches as findings and sends alerts to channels such as email. Wazuh decodes collected logs, compares events against its ruleset and writes alerts that map to MITRE ATT&CK. For network egress, Suricata's EVE output records alerts and flows in JSON, which can be split into separate files for log management. Confirm that each tool can ingest your marker events in the format you choose before you commit to a design, since the markers and the detection rules must match.

How DeployOpen scopes and prepares SI-20 evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so SI-20 work starts from your system design and configuration rather than a generic template. We prepare the systems and evidence that an independent assessor reviews; the organization owns the control decision and the assessor issues any findings.

How we scope

Confirm with your team whether SI-20 is selected in your tailoring or overlay, since no SP 800-53B baseline assigns it.
Define the organization-defined parameter for SI-20, including which systems or components receive embedded markers or capabilities.
Agree in writing which data types, environments and assessment objects are in scope before any work starts.

How we build

Document the system design and configuration settings that the SI-20 examine objects reference, so the marker design is traceable.
Deploy and configure detection rules in the chosen open-source tooling to alert on markers appearing outside expected paths.
Test the detection path end to end with controlled marker events and record the results for the assessor.

How we hand over

Deliver the system design documentation, configuration baselines and alert rule records mapped to the single SI-20 determination statement.
Provide runbooks describing how alerts on markers are triaged, escalated and closed by your security operations staff.
Walk your assessor through the evidence package and the test results, then leave ownership of the controls with your organization.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
Revisit marker placement and detection rules when the system design, data flows or tooling changes.
Ask any partner, including DeployOpen, to confirm in writing which evidence is their deliverable and which remains yours.