What SI-8 spam protection asks for and why assessors care
SI-8 requires spam protection mechanisms at the system's entry and exit points that detect and act on unsolicited messages, and requires those mechanisms to be updated as new releases become available. When an assessor or FedRAMP reviewer asks for SI-8 evidence, they want to see both halves: working filters placed where mail enters and leaves the boundary, and a dated record showing those filters receive vendor or signature updates. SP 800-53B assigns SI-8 to the moderate and high baselines, and FedRAMP's Rev5 baselines require SI-8 and SI-8(2) at Classes C and D. The reason is practical. Unsolicited email is a common delivery path for malicious attachments and links, and phishing messages that reach a user's inbox are often the first step in credential theft. A filter that is configured once and never updated gradually stops catching what attackers are sending, so the update requirement matters as much as the filter itself.
The control is easy to describe and hard to prove. Mail flows are often split across a hosted mail provider, a secure email gateway, a marketing platform, a ticketing system that sends notifications, and sometimes a relay on the organization's own network. Each path can have its own filtering rules, and each may be managed by a different team or vendor. An assessor will ask which paths are in scope, where each one enters or leaves the system boundary, and what evidence shows the filter acted on real traffic. Current records matter most here: filter configuration exports, rule change logs, signature or reputation update timestamps, and sample blocked-message reports dated within the assessment period. A decision to make early is which system owns the SI-8 implementation description, since the assessment procedure examines the spam protection mechanisms and the records of their updates. Confirm the required content of that description against the current FedRAMP guidance before drafting it.
Which mail and network paths fall under SI-8
SI-8 applies wherever unsolicited messages can enter or leave the system, so scope starts with a map of every mail and web path. The cards below cover the decisions that most often change the work: which gateways and relays are inside the boundary, how third-party senders are treated, and how government-facing sending domains alter what a FedRAMP provider must document.
Inbound mail gateways
Inbound gateways receive messages from the internet before they reach mailboxes, so they are the primary entry point SI-8 addresses. Decide whether each gateway that processes system mail is inside the boundary, and record its filtering engine, rule sources and update mechanism. Check that the gateway's spam verdicts are logged and that someone owns tuning and update records. A gateway that sits outside the boundary still shapes evidence if mail for the system passes through it.
Outbound mail relays
Outbound relays carry system messages to external recipients and can be abused to send spam if an account or host is compromised. Confirm which relays send on the system's behalf, who operates them, and whether they filter messages leaving the boundary. Document the relay hosts, authentication method and blocklist monitoring in the SI-8 implementation description so an assessor can trace outbound mail to a control.
Web and network entry and exit points
Spam and unsolicited content also arrive through web forms, APIs and hosted links, not only mail. Map the points where the system accepts external traffic, such as a web application firewall or a stateful firewall, and decide whether each is an SI-8 mechanism or only related to SC-7 boundary protection. Coraza and OPNsense rule logs are common evidence here, but each must be tied to a documented filter update process.
Third-party mail services
Hosted mail filtering and sending services often hold the actual spam protection function, which changes who must produce the evidence. Ask the provider for its update cadence, filter change records and incident history, and confirm whether it is a FedRAMP authorized service. Where the provider is outside your authorization boundary, record the inheritance or customer responsibility split explicitly in the system security plan.
Government-facing sending domains
For a FedRAMP provider, any domain that sends email on behalf of the government changes scope, because FedRAMP guidance expects DMARC on that domain under CISA Binding Operational Directive 18-01 with a reject policy. Inventory each sending domain, its SPF and DKIM records, and its DMARC policy, then document them in the SI-8 implementation description. Confirm the exact DMARC requirements with the current FedRAMP text before finalizing evidence.
Domains that send for the system
Any domain that sends mail for system functions, including alerts, password resets and billing notices, belongs in the scope inventory even if it is not a primary business domain. Attackers spoof these domains, so missing one leaves a gap an assessor can find with a simple DNS lookup. Compare the domain list against the boundary diagram and the SC-5 and SC-38 related controls to confirm nothing sends outside the documented path.
How an assessor tests SI-8
This table maps the SI-8 assessment focus areas in SP 800-53A to the methods an assessor uses, the evidence requested and the findings that appear most often. Confirm the exact wording of the five determination statements in the SP 800-53A Release 5.2.0 OSCAL file before preparing evidence, since the rows group them by theme.
| Assessment focus | How the assessor tests it | Evidence requested | Common findings |
|---|---|---|---|
| Policy and procedures (CM-01) | Examine the configuration management policy and procedures for spam protection scope, owners and update expectations. | Approved policy and procedure with owner, review date and update cadence. | Procedure omits who approves and deploys filter updates. |
| Mechanism placement | Examine system design documentation, then confirm a filter exists at each entry and exit point listed. | Architecture diagram listing mail gateways, relays, web entry points and outbound paths. | Outbound relays or smart hosts are missing from the design documents. |
| Detection and action | Examine filter configuration, then send controlled test messages and confirm the defined action occurs. | Configuration export and dated test results showing quarantine, tagging or rejection. | Filters run in monitor-only mode with no enforced action. |
| Update currency | Examine update records, then compare the deployed rule or signature version with the vendor's current release. | Update logs, rule set versions and change tickets with dates. | Stale signatures or rule sets with no record of the last update. |
| Administrator knowledge | Interview administrators on tuning, alert response, false positive handling and coverage of exit points. | Runbook, on-call roles and sample tickets from recent filter events. | Administrators cannot name every exit point or the update owner. |
| Firewall and gateway logs | Examine logs for blocked or flagged messages and confirm they reach the monitoring process. | Log samples, retention settings and review records (for example, rule match logs in OPNsense). | Logs exist but no one reviews blocked messages. |
| DMARC for government email (FedRAMP) | Query the DNS records of each sending domain and check the DMARC policy and reporting configuration. | DMARC records, sending domain inventory and documented DMARC compliance in the SI-8 description. | DMARC policy set to none, or sending domains missing from the description. |
Implementing SI-8 step by step
This sequence moves SI-8 from a requirement on paper to a documented, tested and maintained spam protection capability, with each step producing the record an assessor will ask to see. The organization owns the control, and an implementation partner can prepare the configuration and evidence while the independent assessor tests it.
Confirm entry and exit points from the system design
Start with the system design documentation and the data flow diagrams for the boundary. Identify every point where messages enter or leave the system, including inbound and outbound mail gateways, web forms that generate email, and any relay used by applications. The output is a list of these points, each tied to a component in the architecture, and the design documents should reflect the same list. An assessor will compare the two, so any gap between the diagram and the list will surface here.
Select and configure filtering at each point
For each entry and exit point, choose the filtering mechanism that detects and acts on unsolicited messages, such as a mail gateway filter, a reverse proxy or web application firewall rule set, or a packet filter that restricts which sources can reach a relay. Open-source options like OPNsense can enforce source, destination and port rules and log each match, while Coraza can apply OWASP Core Rule Set rules to inbound web traffic. Record the configuration in version control, document the action taken on a match (block, quarantine or reject), and confirm the setting with a test message at each point.
Set the update process to follow vendor and rule releases
SI-8 requires filter protections to be updated as new releases become available, so define who watches each vendor or rule source, how often the team checks it, and who approves and deploys an update. Keep a dated record of each update applied, including the release identifier and the test result before rollout. The output is an update procedure and a log of updates, which an assessor will sample against the release history of each tool. Ask the implementation partner and the platform owner to agree on this ownership in writing before go-live.
Define monitoring and response for filter events
Decide which filter events are logged, where the logs are sent, and who reviews them. Define the thresholds or patterns that trigger investigation, such as a sudden rise in blocked messages from one source, and the response steps, including blocking a sender, adding a rule and escalating to incident response. Link this procedure to the system monitoring and incident handling records. The output is a monitoring procedure and sample log entries showing that events were reviewed and acted on.
Test that filtering blocks unsolicited messages
Run controlled tests at each entry and exit point to confirm that unsolicited or policy-violating messages are detected and acted on, and that legitimate traffic still passes. Record the test cases, the expected result, the actual result and the person who verified it. Repeat the test after any rule change or update. The output is a dated test record that supports the test method an assessor may use, and failed tests should link to a tracked remediation item.
Write the SI-8 implementation description
Document how the control is implemented in the system security and privacy plan. The description should name each entry and exit point, the mechanism at each point, the update process, the monitoring and response procedure, and the owner of each activity. Where the system sends email on behalf of a government customer, the FedRAMP guidance for SI-8 also expects the DMARC implementation on the sending domain, with a reject policy, and the sending domains to be documented in this description. The output is a reviewed implementation statement that matches the configuration and test records.
Prepare the evidence package for the assessor
Gather the artifacts an assessor will examine: the configuration policy and procedures, the filter configuration exports, the records of spam protection updates, the system design documentation and the test records. Check that each item is dated, current and consistent with the implementation description. Confirm with the assessor which evidence format they accept. The independent assessor performs the testing and issues the findings. The output is an indexed evidence set mapped to the SI-8 assessment objects.
What FedRAMP expects for DMARC on government email
FedRAMP expects a provider that sends email on behalf of the government to implement DMARC on every sending domain, following the approach described in CISA Binding Operational Directive 18-01, with a reject policy. The SI-8 implementation description must state that DMARC is in place and list each sending domain. SI-8 and its enhancement SI-8(2) apply at Classes C and D under FedRAMP's Rev5 baselines, so this is an assessed item, not a recommendation. Confirm the current wording of the requirement against the FedRAMP Full Rev5 reference for SI-8 and the Consolidated Rules before you write the control narrative, because the rules are versioned and the assessor will test against the version in force for your authorization.
To verify the DNS side, query the _dmarc TXT record for each sending domain and confirm the p= tag is reject. Check that the record is published at the apex of the domain that appears in the From header, and that subdomains used for sending either inherit a correct policy or have their own explicit record. Also review the aggregate and forensic reporting addresses in the record and confirm someone reads those reports. A reject policy only protects the government if SPF or DKIM alignment passes for legitimate mail, so test each sending service, including marketing and transactional platforms, before tightening the policy. Keep dated screenshots or exported DNS query results as evidence.
For each sending domain, record the domain name, the business purpose of the mail stream, the sending services that use it, the exact DMARC record and its publication date, the SPF and DKIM configuration that supports alignment, the owner who approves changes, and the date of the last report review. Store this register with the system security and privacy plan so that the SI-8 narrative and the assessor's examine objects point to the same data. Illustratively, a provider with a support ticketing tool and a billing notification service would list both domains separately, because a single policy on the parent domain does not cover a subdomain that has its own record. Ask your assessor early which evidence format they accept for DNS records.
Evidence that passes an SI-8 review
An assessor testing SI-8 will look for proof that spam filters exist at every entry and exit point, that they are kept current, and that someone reviews what they catch. The cards below cover the artifacts that show this, and the routine that keeps each one accurate between assessments.
Spam protection configuration exports
Export the active configuration of every mail gateway, relay and filtering service that sits at a system entry or exit point, including filter policies, quarantine actions and reject settings. Store the export with a date and the change ticket that produced it. Between audits, regenerate the export after each change window and diff it against the last copy, so a reviewer sees what changed and why. Confirm the export covers inbound and outbound paths, since an assessor will test both.
Records of filter and rule updates
SI-8 requires spam protection to be updated as new releases become available, so the assessor will ask for a dated history of signature, rule and engine updates. Keep the vendor or community release notes you applied, the date each one reached production, and any update you deferred with a documented reason. Review the record monthly so gaps show up before the assessor finds them.
SI-8 implementation description with sending domains
The implementation description states which mechanisms protect each entry and exit point, who operates them, how updates are applied, and how the organization monitors effectiveness. Where the organization sends email on behalf of others, FedRAMP's expectations also call for the sending domains listed here. Assign an owner to refresh the domain list whenever a new sender, marketing platform or third-party service is onboarded.
DMARC records and aggregate reports
For providers that send email for the government, FedRAMP expects DMARC on each sending domain under CISA BOD 18-01 with a reject policy, documented in the SI-8 description. Keep a copy of each DMARC TXT record, the policy history showing when enforcement moved to reject, and the aggregate reports that show legitimate senders pass alignment. Check the records after any DNS change, because a single edit can silently weaken the policy.
Alert and block logs
Logs of quarantined, rejected and flagged messages show that the mechanisms actually act on unsolicited mail. Retain them under the organization's log retention schedule and sample them on a fixed cadence, looking for false positives that block business mail and for spam that gets through. Record each review outcome so the sample itself becomes evidence.
Design diagrams of entry and exit points
A current diagram shows every path where mail or web traffic enters or leaves the system, and the filter placed on each path. Assessors compare the diagram against the configuration exports to confirm nothing sits outside the filtering. Redraw it whenever a gateway, relay or firewall rule changes, and tie the version number to the SI-8 description. Firewall rule exports from OPNsense can supply the network-side detail for this diagram.
What meeting SI-8 costs in money and effort
This table breaks down the cost components of meeting SI-8 Spam protection, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request, because no price figures are supplied for these components and the real numbers depend on your entry and exit points, sending domains and chosen tooling.
| Cost component | One-time or recurring, and who is paid | What drives the cost |
|---|---|---|
| Licensed or hosted filtering | Recurring. Paid to a commercial filtering vendor or hosting provider; open-source filtering removes this license line | Number of entry and exit points, message volume and whether filtering is hosted or self-operated |
| Engineering time to configure and integrate | One-time, with some recurring tuning. Paid to internal staff or an implementation partner under a written scope | Mail gateways, web entry points and relays in scope, plus integration with existing logging and alerting |
| Update upkeep for filters and signatures | Recurring. Internal staff or a retainer must apply new releases and rule updates as SI-8 requires | How many filter components run, how fast vendors or projects publish updates, and change control overhead |
| DMARC monitoring and enforcement | One-time setup, then recurring review of reports. Internal staff or a managed provider; needed where the organization sends email for the government under FedRAMP expectations | Number of sending domains, third-party senders that must be aligned and volume of aggregate report data to review |
| Documentation for the SI-8 implementation description | One-time, with updates on each change. Internal staff or consultant time | Number of mechanisms, sending domains and how often configuration changes |
| Auditor sampling and evidence requests | Recurring per assessment cycle. Paid to the independent assessor, not to the implementation partner | Number of entry and exit points sampled, depth of records requested and quality of pre-built evidence |
| External testing of filtering | Recurring or per engagement. Paid to a testing firm if independent validation is required | Scope of tested paths, whether phishing or relay abuse is tested and retest needs |
| Self-hosted open source (for example, OPNsense or Coraza) | Removes most license spend. Shifts configuration, patching, log review and rule maintenance to the organization | Staff skills, hosting in the organization's own infrastructure and the depth of logs kept for review |
Open-source tools that support SI-8 evidence
Coraza is a self-hosted web application firewall licensed under Apache-2.0. It is compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, and it is designed to detect attacks such as SQL injection, cross-site scripting and code injection in HTTP traffic. It integrates with Caddy, HAProxy, Traefik and Nginx, so it can sit in front of an existing web tier. Coraza addresses web attack patterns, not mail. It does not filter email, and it should not be cited as the SI-8 mechanism for messages.
- Placement evidence: Configuration files and proxy definitions show where Coraza runs relative to each public application, which supports the claim that entry points are covered.
- Rule set records: The version and source of the loaded rule set, along with the update history, can serve as records of spam protection updates for the web tier.
- Action logs: Blocked and logged requests show that the mechanism detects and acts on unwanted input.
- Scope limit: Coraza covers HTTP and HTTPS entry points only. Contact forms that send mail must be assessed on the mail path.
Confirm with the team that operates the web tier which ruleset version is loaded, how often it is updated, and whether the proxy in front of each application runs Coraza.
OPNsense is an open-source firewall distribution licensed under BSD-2-Clause. Its stateful packet filter passes, blocks or rejects traffic by source, destination, port and protocol. Aliases group addresses so one rule can cover a set of hosts, and each rule can log its matches to the live log view. These features give an organization a boundary record for both inbound and outbound traffic, which is the layer where unsolicited connections at system entry and exit points are typically controlled.
- Rule export: The rule set, exported or backed up from the firewall, shows which inbound and outbound paths are permitted or blocked.
- Alias definitions: Named aliases for mail relays and known sources document which addresses are treated differently.
- Logging evidence: Per-rule log entries for matches show that filtering is active and reviewed.
- Change history: Configuration backups taken before and after changes provide a record of filtering updates.
- Scope limit: A packet filter inspects addresses, ports and protocols. It does not classify message content, so it does not by itself prove that unsolicited email is detected.
Confirm whether SMTP traffic is restricted to approved relays at the boundary, and whether the rule log retention period meets your evidence requirements.
SI-8 is aimed at unsolicited messages, and mail is the most direct case. Neither Coraza nor OPNsense is documented here as a mail content filter, so mail-specific filtering must be confirmed separately. The question is whether the organization runs a mail gateway or hosted service that performs spam and phishing classification at the inbound and outbound mail entry points, and whether that component is updated as new releases become available. For providers that send mail for government customers, FedRAMP's DMARC expectation applies to the sending domain.
- Gateway records: Gateway configuration, classification policies and update logs show the filtering in place.
- Quarantine and disposition reports: Records of messages held or rejected support the claim that the mechanism acts on unsolicited mail.
- DMARC configuration: Published DMARC records with a reject policy and a list of sending domains feed the SI-8 implementation description where FedRAMP applies.
- Outbound checks: Evidence that outbound mail is filtered reflects the exit point requirement.
- Scope limit: Open-source mail tools vary in filtering depth. Confirm the capability and update process before naming any tool in the implementation description.
Ask the mail platform owner to produce the gateway configuration, update history and current DMARC record for each sending domain.
Where SI-8 programs usually fall short
SI-8 looks simple on paper, but most gaps appear where mail enters and leaves the boundary, where filter updates go unrecorded, and where government sending domains are not protected. The cards below cover the gaps assessors most often find and a practical fix for each, starting with the components that receive and relay mail.
Unknown mail entry and exit points
Teams often document the primary mail gateway but miss secondary MX records, legacy relays, application servers that send notifications, and scanners that email scanned documents. SI-8 expects spam protection at every system entry and exit point, so an unlisted path is an uncovered path. Build a list from DNS MX records, mail flow rules and outbound SMTP logs, then confirm each path is filtered. Ask the system owner to sign off on the list.
No record of filter updates
Filters are often updated automatically, but nobody keeps evidence of when the rule sets or reputation data changed. SI-8 requires that protection mechanisms are updated as new releases become available, and assessors examine records of those updates. Keep an update log from the filter platform or configuration management system, and set an alert when an update fails or falls behind. A screenshot taken during the assessment does not show history.
DMARC left at none or quarantine
Government sending domains are sometimes configured with a DMARC monitoring policy or a quarantine policy and left there for years. FedRAMP guidance for SI-8 expects providers that send email for the government to apply DMARC on the sending domain with a reject policy, as described in CISA Binding Operational Directive 18-01. Review each sending domain's published DMARC record, move it to reject once legitimate senders pass SPF or DKIM alignment, and keep the record in version control.
Implementation description omits sending domains
The SI-8 implementation description often names the filtering product but not the domains it protects. FedRAMP expects the description to document DMARC compliance and the sending domains covered. Without that list, an assessor cannot tell whether a domain that sends government mail is covered at all. Maintain the domain inventory as a controlled document, reference it from the SI-8 description, and update both when a domain is added or retired.
Outbound relays outside the boundary
Organizations sometimes route outbound mail through a third-party relay or a SaaS sending service that sits outside the authorization boundary and is not described in the system security plan. Spam and malicious mail leaving through that path may never reach the filter in scope. Identify every relay in the outbound path, document it as part of the system or as an external service with its own agreement, and confirm the filter applies to traffic before it leaves the boundary.
SI-8 questions buyers ask before hiring help
How much effort does SI-8 spam protection take to implement?
Effort for SI-8 is driven less by the control itself and more by how many entry and exit points handle email and web traffic, and how many of those already have filtering. The control asks for spam protection at system entry and exit points, kept up to date as new releases appear, so the work is mostly inventory, configuration, and recurring update handling. Ask any partner to split its quote into one-time setup (mapping mail and web paths, configuring filters, writing the implementation description) and recurring work (updating filter content, reviewing logs, and re-collecting evidence for each assessment cycle). Confirm with your assessor which evidence they expect before you agree on scope.
How long does SI-8 preparation usually take?
The duration depends on scope drivers rather than a fixed figure. The main drivers are the number of email gateways, relay services, and boundary devices that need filtering, whether those components are already managed by the same team, whether the system sends email for government customers, and how much existing configuration history exists to show update records. A system with one documented gateway and recent update logs will move faster than a distributed environment with several undocumented relays. No duration is set by NIST for this control, so ask your assessor and your partner to agree on milestones in writing before work starts.
What does the organization need to provide before work starts?
The organization owns the control, so it must supply the facts an implementation partner cannot invent. Prepare a current list of systems that accept inbound messages or send outbound messages, the mail domains in use, the filtering products and their vendors, and the people who approve configuration changes. Gather existing policies and procedures for system and information integrity, and records showing when filter content or signatures were last updated. Also decide who accepts risk for any gaps. Without these inputs, the system design documentation the assessor will examine cannot be completed accurately.
Can our team implement SI-8 without outside help?
Yes, an internal team can implement SI-8 if it has the skills to configure filtering at each entry and exit point, keep the update process running, and produce evidence in the form the assessor will examine. The questions to answer honestly are whether someone owns filter updates on a fixed schedule, whether logs and change records are retained, and whether the team can write an implementation description that matches what is deployed. Outside help is most useful when the environment has many boundary components or when the team needs an independent check before an assessment. DeployOpen plans and implements self-hosted platforms in your own infrastructure and prepares evidence, but it does not issue audit reports or certifications.
What does FedRAMP's DMARC expectation for SI-8 require?
For providers that send email on behalf of the government, FedRAMP guidance for SI-8 expects DMARC to be implemented on the sending domain as described in CISA Binding Operational Directive 18-01, with a reject policy. The implementation description must also document DMARC compliance and list the sending domains. In practice, this means publishing and verifying DMARC records for each domain, moving the policy to reject only after reviewing aggregate reports, and keeping records of those changes. Confirm the exact expectations for your authorization with your FedRAMP assessor and the current FedRAMP SI-8 reference before you publish the policy.
What can an implementation partner sign off, and what can it not?
An implementation partner can prepare the configuration, documentation, and evidence for SI-8, and can test that filtering behaves as described. It cannot issue an assessment report, attestation, or authorization decision. Those are reserved for an independent assessor, a certification body, or the authorizing official in your program. Ask any partner to state in writing which artifacts it delivers (configuration exports, update records, implementation text, DMARC records) and which decisions remain with you and your assessor. Under FISMA, Inspectors General independently assess agency systems, so the partner's work is an input to that independent review, not a substitute for it.
How DeployOpen prepares SI-8 evidence
The sequence turns SI-8 spam protection from a control statement into deployed filtering, documented configuration and an evidence package that an independent assessor can test against the SP 800-53A procedures. DeployOpen prepares and documents; the organization owns the control and the assessor decides whether it is met.
Agree scope and deliverables in writing
Before any work starts, DeployOpen and the client agree in writing which systems, mail flows and entry and exit points fall inside SI-8, which baseline applies (moderate or high under SP 800-53B, or the FedRAMP Rev5 classes if relevant), and which deliverables will be produced. The client owns the control and its risk decisions, so it confirms who signs off on the filtering policy. The output is a signed scope statement that names the assessed boundary and the evidence list.
Inventory entry and exit points for unsolicited messages
DeployOpen maps where unsolicited messages can enter or leave the system, including inbound mail gateways, web and API ingress, outbound mail relays and any service that sends mail on the organization's behalf. The client confirms the inventory against its own network and system design documentation, which the assessor will examine. The output is a boundary diagram listing each point, the mechanism that handles it and the owner responsible for it.
Deploy and harden filtering at each point
Using self-hosted tools in the client's own infrastructure, DeployOpen deploys filtering at the identified points. Where web traffic is concerned, Coraza (Apache-2.0) can run as a web application firewall with ModSecurity SecLang rulesets and the OWASP Core Rule Set, integrated with a supported reverse proxy. Where network traffic is concerned, OPNsense (BSD-2-Clause) rules can pass, block or reject traffic by source, destination, port and protocol. The client confirms that each mechanism's capabilities match its own requirements for unsolicited message handling. The output is a tested configuration that blocks and logs the intended traffic.
Set the update process for filters and rules
SI-8 requires spam protection mechanisms to be updated as new releases become available, so DeployOpen documents how rule sets, signatures and software versions are pulled, tested and promoted to production, and who approves each change. The process ties into the configuration management records the assessor will examine under CM-01. The output is a written update procedure and a change log template that records each filter update.
Configure logging and review of filter activity
DeployOpen enables logging of filter matches and rule decisions where the chosen platform supports it, for example OPNsense can log each rule match for review in its live log view. The client confirms retention and who reviews the logs, and the links to monitoring under SI-4 are documented. The output is a sample of logged events showing blocked messages, and a description of how the organization reviews them.
Document the SI-8 implementation description
DeployOpen writes the implementation description with the client, covering the mechanisms at each point, their configuration baseline, update records, responsible roles and related controls such as SI-3, SI-4, SC-5, SC-7 and SC-38. Where the system sends email for a federal customer, the description also records the DMARC configuration on each sending domain, with a reject policy, as FedRAMP guidance expects. The output is a controlled document the client approves and maintains.
Assemble the evidence package for the assessor
DeployOpen gathers the artifacts that map to the SP 800-53A examine, interview and test objects: policies and procedures, the configuration of each filter, update records, the system design documentation and sample filter logs. It checks that each artifact matches the documented configuration. The output is an evidence index that cross-references each item to the relevant assessment objective, so the independent assessor can select and test samples. DeployOpen does not issue audit reports, attestations or certifications; the independent assessor performs the test and issues the findings.
Support ongoing updates through a retainer
After the initial deployment and evidence package, the client may keep DeployOpen on a retainer for ongoing updates, configuration reviews, filter maintenance and evidence refreshes when the system changes. Retainer terms, scope and cadence are agreed in writing, and the client remains responsible for approving changes and for the control itself. The output is a maintained configuration baseline and updated evidence records ready for each assessment cycle.
