SC-35 external malicious code identification guide

What SC-35 external malicious code identification asks for

SC-35 requires that system components proactively seek to identify network-based malicious code or malicious websites. The key word is proactively: the control expects components that go looking for threats on networks, including the internet, rather than only waiting for threats to arrive. No SP 800-53B baseline includes SC-35, so it applies only when your organization selects it through tailoring or an overlay, or when a contract or authorizing body requires it. If you have been told it is in scope, first confirm which document or decision placed it there, because the answer determines who must evidence it.

The risk it addresses is different from the inbound protection most teams already run. Malicious code protection (SI-3) and system monitoring (SI-4) react to traffic and files that reach your systems. SC-35 asks for a capability that looks outward: components that identify malicious sites or code on the networks your systems depend on, so that a threat is recognized before a user or process is exposed to it. In practice, teams often satisfy this with a mix of network intrusion detection, threat intelligence feeds and sinkholing, and the boundary policy in SC-7, but none of those is automatically SC-35. Confirm with your assessor whether an existing sensor counts as a component that proactively seeks threats, or whether you need a separately identified one.

Evidence is hard to produce for an outward-facing capability because it lives in configuration and logs rather than in a single artifact. An assessor using the SP 800-53A procedure will look at the system components deployed for this purpose, the system design documentation that shows where they sit, the configuration settings with their supporting documentation, and the audit records showing the component ran and produced results. Ask early whether your sensors keep those records long enough to demonstrate operation across an assessment period, and whether your design documents name the component that performs this function.

Which systems and boundaries SC-35 covers once you select it

SC-35 is not in any SP 800-53B baseline and FedRAMP's Rev5 baselines do not require it at Class B, C or D, so the first scoping choice is whether to select it at all. Once selected, the system security plan defines which components, networks and teams carry it, and each card below is one of those decisions.

Decide whether to select SC-35

Because SP 800-53B does not assign SC-35 to any baseline, the organization must choose it through tailoring or an overlay. FedRAMP's Rev5 baselines do not require it at Class B, C or D, so a FedRAMP-bound system will not need it by default. Record the selection and its rationale in the system security plan, and confirm with the authorizing official or contract owner whether any other requirement adds it. An unselected control still needs a documented reason.

Identify the outward-facing sensors

SC-35 applies to components that actively look for malicious code or malicious websites on networks, including the internet. Typical candidates are an IDS or IPS sensor at the egress point, a web proxy with reputation checks, a URL crawler, or a sandbox that fetches content. Inventory each one, its network position and what it reaches out to, because a passive sensor that only watches inbound traffic may not meet the control's intent.

Map the websites and networks examined

Define the scope of what the components examine: which egress paths, which destination networks, and which web categories or domains. Assessors look for evidence that the identification covers the traffic the system actually sends and receives. Document exclusions, such as encrypted flows that are not inspected or internal ranges that are out of scope, and note who approved each exclusion and why.

Assign tooling ownership

Name the team that operates each sensor, rule set and log pipeline. Network engineering often runs the firewall or IPS, security operations watches the alerts, and platform engineering maintains the hosts. Write these responsibilities into the control implementation statement so an assessor can trace who configures, reviews and updates the identification capability. Unclear ownership is a common reason evidence is missing at assessment.

List third-party feeds and hosted services

Threat intelligence feeds, reputation services, hosted sandboxes and managed IDS rule subscriptions may all contribute detection. Each is a dependency with its own terms, update cadence and data handling. List them in the system inventory, confirm which data leaves your boundary when a URL or file is submitted, and add the provider to supply chain and third-party review. Ask providers for the details of their detection coverage rather than assuming it.

Connect scope to the system security plan

Scope follows the selection recorded in the system security plan, not the baseline. Once SC-35 is selected, the plan should name the components, boundaries, owners and feeds listed above, and the assessment procedure's examine objects should match that list. If the plan and the architecture diverge after a change, update the plan and reassess the affected components so evidence reflects the system as it runs.

How an assessor tests SC-35 external malicious code identification

This table walks through how an SP 800-53A assessor approaches SC-35, which has a single determination statement and four kinds of assessment objects. Read each row as what the assessor will ask for, look at, or try, and use the evidence and findings rows to prepare before fieldwork begins.

Row	What it means for the assessor	What to prepare
Test approach	The assessor determines whether the organization has deployed system components that proactively look for network-based malicious code or malicious websites, then checks that those components run as designed.	Confirm which components in your boundary perform this function and document why each one is in scope.
Determination statement	There is one determination statement for SC-35. The assessor must conclude that components actively seeking malicious code or malicious websites are identified in the system and operating.	Write a short statement that names each component, its location in the architecture, and what it detects.
Examine method	The assessor reviews documents and configuration: design documentation, configuration settings, and related documentation, to confirm the detection components exist and are set up to look for malicious content.	Keep current design diagrams, rule set lists, signature sources, and configuration exports with version dates.
Interview method	The assessor talks with the people who operate the detection components and respond to their alerts, to confirm they understand scope, tuning and escalation.	Name an owner for each component and make sure that person can explain its rule updates and alert handling.
Test method	The assessor observes the components working, for example by checking that a known test indicator produces an expected detection or that a blocked site is logged.	Plan a controlled test with safe, approved test indicators and record the outcome, including any misses.
Assessment objects	Four objects are examined: the malicious code and malicious website detection components, system design documentation, configuration settings with related documentation, and system audit records.	Gather each object in one folder so the assessor can trace component, design, configuration and logs together.
Evidence requested	Typically: architecture diagrams showing where detection sits, configuration files, rule or signature source records, sample alert and audit log entries, and test results.	Export evidence from the components directly where possible, and confirm the log retention period with your assessor before fieldwork.
Common findings	Components described in design documents but absent from the live configuration, undocumented signature sources, alerts that no one reviews, and no test showing detection works.	Reconcile design documents against configuration exports and close gaps before the assessment starts.

How to implement SC-35 in five steps

This sequence takes SC-35 from a selection decision to a documented, testable detection capability, producing the rationale, component inventory, configuration, evidence flow and design documents that an assessor will examine.

Decide and record whether SC-35 applies
Start by checking whether SC-35 is selected for the system at all. SP 800-53B does not place it in the low, moderate, high or privacy baseline, so it enters the control set only through tailoring or an overlay that your authorizing official or compliance lead approves. Record the decision, the reason for it (for example, a threat that involves malicious websites reaching users or systems), and the people who approved it. The output is a short rationale entry that feeds directly into the system security plan, where the selected controls and their tailoring decisions are documented. The step is done when the rationale names the threat, the system boundary and the approver, and the plan references it.
Define the components and traffic they examine
Inventory the system components that will proactively look for network-based malicious code or malicious websites, and state exactly what each one examines. Typical candidates are an intrusion detection and prevention layer on a firewall or perimeter appliance, and network sensors placed on the segments where outbound web traffic and inbound content cross a boundary. Map each component to the websites, network segments and protocols it covers, and note what it does not cover. Confirm with your network team and the platform vendor which traffic is visible to each component, including encrypted traffic. The output is a component register with coverage statements that an assessor can compare against the network diagram. The step is done when every covered segment appears in the register and every gap is listed.
Deploy and configure identification components
Install the chosen components inside your own infrastructure and configure them to identify malicious code and websites. For example, OPNsense (BSD-2-Clause) includes a built-in intrusion detection and prevention system that runs Suricata with rulesets such as Emerging Threats and Abuse.ch, and can alert on or block matching traffic. Set the rule sources, update schedule, alert or block mode per category, and the interfaces monitored. Keep the configuration under version control so changes can be traced. Test detection with known benign test signatures in a non-production segment and record the results. The step is done when the configuration is exported, the update process is documented, and the test results show that alerts fire for the covered segments.
Route alerts and records into log and threat intelligence tools
Send detection output to the systems that will retain and review it. Suricata's EVE JSON output records rule match alerts, protocol transactions such as HTTP and DNS, file information and engine statistics, and can be split into separate files for log management tools. Forward these records to your central log platform, and where you hold indicators of malicious websites or code, use a threat intelligence platform such as MISP (AGPL-3.0-only) or OpenCTI (Apache-2.0) to correlate them and generate detection rules. Define who reviews alerts, how false positives are handled and how indicator feeds are approved. The step is done when a test alert appears in the log platform with the fields you need, and the review workflow is written down.
Write the configuration and design documentation
Prepare the documents an assessor will examine for SC-35: system design documentation showing where the identification components sit, system configuration settings with their associated documentation, and the audit records that show the components operated. Include the component register, the rule source and update procedure, the alert handling procedure and the tailoring rationale from the first step. Cross-reference each document to the SC-35 determination statement in SP 800-53A so the evidence is easy to find. Ask your assessor early which format they accept. The step is done when a reviewer who did not build the system can trace from the control statement to the design, the configuration and a sample of audit records.
Confirm the control operates and keep it current
Run a final check that the components detect what the documentation says they detect, then schedule recurring checks. Verify that rule updates are applied, that alerts reach the review queue, and that coverage still matches the network diagram after changes. Record each check with date, person and outcome, and feed any gaps into the plan of action and milestones. Whether an independent auditor or assessor accepts this evidence is their decision, not yours, so confirm the expected evidence format with them before the assessment window. The step is done when a dated verification record exists, any gaps are tracked, and the documentation reflects the current configuration.

Open-source tools that produce SC-35 evidence

SC-35 asks for components that actively look for malicious code and malicious websites, so the evidence is usually sensor alerts, configuration records and threat intelligence handling. The four tools below can produce parts of that record, but each one covers a different layer, and each carries a license obligation that should be reviewed before deployment.

OPNsense intrusion detection

OPNsense ships a built-in intrusion detection and prevention system that runs Suricata and can load rulesets such as Emerging Threats and Abuse.ch. The IPS can alert on or block matching traffic, and alerts can be sent to syslog in EVE JSON format. For SC-35, the key checks are which rulesets are enabled, whether the sensor sees traffic at the boundary where malicious content enters, and whether configuration exports can show the enabled rules at the time of assessment. Confirm how the feature fits your firewall version and deployment. OPNsense is BSD-2-Clause, but the Suricata component it runs is GPL-2.0-only.

Suricata EVE output

Suricata is the detection engine behind many open-source network sensors, and its EVE output writes structured JSON records for rule alerts, flows, protocol transactions such as HTTP and DNS, file information and engine statistics. Those records are the strongest evidence that a sensor actively inspected traffic for malicious content. Split the output into separate files for alerts, HTTP and DNS so an assessor can trace a detection back to the sensor configuration and the log record. Suricata is GPL-2.0-only, so ask counsel how distributing modified builds or bundled rules affects your obligations.

MISP indicator sharing

MISP correlates indicators by exact match and advanced patterns, records sightings and synchronizes events between instances using sharing groups and distribution controls. It can export indicators as Suricata, Snort and Zeek rules, which connects threat intelligence to the sensors that inspect traffic. For SC-35, sightings and rule export logs show that malicious website and code indicators were received, tracked and pushed to detection. Confirm how your sharing agreements define distribution, and ask counsel how the AGPL-3.0-only license applies if you modify MISP and make it available to users over a network.

OpenCTI threat intelligence

OpenCTI organizes threat intelligence as STIX-based entities and relationships and ingests data through connectors, TAXII, RSS, CSV and JSON feeds or manual upload. Its value for SC-35 is the record it keeps of which malicious website and code intelligence the organization received, from which source and how it was linked to observables. Confirm which connectors you run and how feed content is reviewed before it reaches detection rules. OpenCTI is Apache-2.0, which is permissive, but connector and feed terms still need review by counsel.

Which SC-35 evidence passes and how to keep it current

What should the system security plan say about SC-35 selection?

The system security plan should state whether SC-35 is selected, the reason it is selected or excluded, and who owns it. SC-35 is not assigned to any SP 800-53B baseline, so an assessor will look for a documented tailoring decision rather than an assumed default. The entry should name the components that perform the identification, such as network sensors or threat intelligence feeds, and point to the design and configuration documents that describe them. If the organization selected SC-35 through an overlay or its own tailoring, record that source too. Review the entry at each significant change to the boundary, because a decision made for one architecture may no longer hold after a migration. The organization owns this decision. An implementation partner can draft the entry from the design, but the authorizing official or control owner must approve it.

What design documentation shows how identification components work?

Design documentation should show where each identification component sits, what traffic it inspects, what it compares against, and where its output goes. An assessor checks that the diagram matches the deployed system and that the components are placed where they can see network-based malicious code or malicious websites. For a self-hosted stack, this often means a firewall running an intrusion prevention system, a sensor exporting protocol logs, and a threat intelligence platform that supplies indicators. Describe the data flow between them and the owner of each step. Store the document under version control, date each revision, and tie each revision to a change ticket. Keep a short note on which rule sources are enabled and why, so the design can be checked against the configuration exports described in the next item.

Which configuration exports and change records prove the controls are in place?

Configuration exports prove what is running, and change records prove how it got there. Export the firewall's intrusion prevention settings, enabled rulesets, alert and block actions, and syslog destinations on a fixed schedule, and keep each export with its date and the system that produced it. For Suricata-based setups, the relevant files are usually the main configuration file and the rule source list, so store those with a hash or checksum. Every change to rule sources, actions or destinations should have a ticket that states the reason, the approver and the test performed. An assessor will compare a recent export with the design document and with the tickets, looking for gaps such as a ruleset that was disabled without approval. Ask your team to confirm how often exports are taken in your environment, since the appropriate frequency depends on your change rate and your own control schedule.

What audit records and alert logs show the components operating?

Audit records and alert logs show that the components ran during the assessment period, which is stronger evidence than configuration alone. Collect alert samples from the intrusion prevention system and the protocol logs from the sensor, including HTTP and DNS transactions where those are relevant to malicious websites. Suricata's EVE JSON output can write alerts and protocol records to separate files, which makes it easier to filter and retain them. Keep a dated extract for each period, record the retention setting, and confirm that log transport to the central store is working by reviewing gap reports. Look for periods where alerts stopped, because an assessor may ask why. Test a known benign indicator, such as a sample from a test ruleset, and keep the result. Retention periods should follow your organization's audit policy rather than a figure taken from this page.

How should threat intelligence sources and sharing records be kept?

Threat intelligence records should show which sources feed the identification components, when each was added or updated, and how indicators were used or shared. Keep a source register that lists each feed, its owner, its licence terms and its update method. For a self-hosted platform, MISP can synchronize events between instances with sharing groups and record sightings, while OpenCTI organizes indicators as STIX-based entities and ingests them through connectors and TAXII feeds. Export the sharing and sighting logs with dates, and keep the rule exports generated from those indicators. Assessors often ask whether feed content is reviewed before it reaches blocking rules, so record that review step. Confirm the licence terms for any commercial or community feed with its provider before you rely on it in an assessment.

How often should the SC-35 review schedule run between audits?

The review schedule should set a recurring date for each evidence artifact, a named owner, and a trigger for an unscheduled review. Most organizations pair a periodic review with event-driven reviews after architecture changes, new rule sources or a significant incident. The interval should be set by the organization's own control and risk policy, and confirm it with your assessor before the audit begins. Track each review in a register with the date, the reviewer, the findings and the linked tickets. Use dated exports so that every review compares like with like. Setting the schedule is an internal decision. An implementation partner can build the calendar and evidence templates in a fixed-scope engagement, but the organization runs the reviews and owns the results. Independent assessors test the evidence; they do not produce it for you.

What meeting SC-35 costs in money and effort

This table breaks the cost of meeting SC-35 into its components, showing who is paid, whether each cost is one-time or recurring, what drives it and how to reduce it. Because SC-35 is not in any SP 800-53B baseline, the spend depends almost entirely on whether your organization selects the control through tailoring or an overlay. No prices are given here, so use the quote checklist to compare written scopes.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring if commercial; none for open source	Commercial sensor or threat detection products priced by traffic, endpoints or deployment scope	Use self-hosted open-source detection such as Suricata with OPNsense, which carries no license fee for the software itself
Engineering time to deploy and configure	One-time, with periodic tuning	Number of network sensors, placement at boundaries, rule tuning and integration with logging	Fix a narrow scope first, reuse existing firewall hardware, and ask the implementer to document the configuration as code
Threat intelligence feed subscriptions	Recurring if paid; many feeds are free or open	Number of commercial feeds, licensing terms for sharing, and volume of indicators ingested	Start with free community rulesets and open feeds, then add paid sources only where your risk assessment justifies them
Threat intelligence platform operation	Recurring staff time, plus one-time setup	Number of indicator sources, sharing communities and whether analysts triage events manually	Self-host an open platform such as MISP or OpenCTI and limit ingestion to sources that feed your detection rules
Evidence upkeep	Recurring	Frequency of rule and configuration changes, retention periods for alerts, and the number of systems in scope	Export configuration and alert samples automatically to your log store, and tie each change to a ticket
External testing or review	Recurring or per engagement	Whether a tester must prove that malicious code and malicious site detection works, and how deep the test goes	Scope the test to the boundary sensors and detection rules, and retest only after material changes
Auditor sampling	Recurring per assessment cycle	How many sensors, alert records and tuning changes the assessor samples, and how well evidence is organized	Keep a single evidence index that names each sensor, rule source and alert log, so sampling takes less staff time
Quote and scope definition	One-time	Whether the tailoring decision, system boundary and assessment objects are agreed in writing before work starts	Ask the provider to state in writing which SC-35 assessment objects are covered and which are your responsibility

Who does what for SC-35 in-house, with a partner, and with the auditor

Your organization owns SC-35. The decision to select it belongs to you because the control is not in any SP 800-53B baseline, so it enters a system only when your tailoring or overlay adds it. Your team also owns the outcome. The components that look for malicious code and malicious websites must run, be monitored and be acted on by people you employ or contract under your own accountability.

Selection decision: Record why SC-35 is in scope for this system, such as a threat model or tailored baseline that calls for proactive detection of network-based malicious code, and who approved that choice.
System security plan entry: Describe which components perform the function, where they sit, what they inspect and who operates them. Keep the entry consistent with the related controls SC-7, SI-3 and SI-4.
Operation and tuning: Keep detection rules and threat intelligence feeds current, review alert volumes and document false positives and the reasons for each tuning change.
Alert handling: Route alerts to a named queue, define triage and escalation steps, and pass confirmed events into your incident response process.

Check that every item above has a named owner inside your organization, because an assessor will ask who answers for each one.

Where SC-35 programs usually fall short

SC-35 is a control organizations often select quickly and document thinly. The gaps below share a root cause: the control is adopted as a label, not as a set of decisions, sensors, records and reviews that an assessor can trace.

Selecting the control without a rationale

Teams often add SC-35 to a system security plan because a scanner or threat feed exists, without writing down why the system needs external malicious code identification. SP 800-53B does not place SC-35 in any baseline, so its presence has to come from a tailoring decision or overlay. Record the threat or mission reason, the components selected to meet it, and who approved the choice. Ask the assessor which evidence they expect for a control that is not baseline-driven before the assessment starts.

Sensors deployed without examine records

SP 800-53A examines system components deployed to identify malicious websites or web-based malicious code, along with design documentation and configuration settings. A sensor that is running but not described in the design documents, with its rulesets and scope unrecorded, gives the assessor nothing to examine. For each sensor, document its location in the architecture, the traffic it inspects, the rulesets or feeds it loads, and the configuration file that controls them. Export that configuration on a fixed schedule so the record matches what is running.

Alerts collected without audit records

Detection output is often sent to a dashboard and then rotated out, so the organization cannot show what the component saw or what it did. SP 800-53A also examines system audit records, which means the alerts, blocks and their handling must persist. Forward alert records to a central log store with defined retention, and keep the link between each alert and the response ticket. Confirm with your log platform that retention and access controls match the period your assessor will sample.

Feeds used without reviewing sharing terms

Threat intelligence feeds and shared indicators carry licenses and distribution rules that the organization may not have read. Using a feed in production without knowing whether its terms allow commercial use, redistribution to partners or automated blocking can create a compliance problem of its own. Maintain an inventory of every feed and sharing group, with its license, permitted uses and owner. Review each source when it is added and when its terms change, and treat the review as part of the SC-35 evidence.

Treating SI-3 or SI-4 as sufficient

Organizations sometimes assume that malware protection under SI-3 or monitoring under SI-4 already covers SC-35. The related-control list places SC-35 alongside SI-3 and SI-4, but SC-35 asks for something specific: components that proactively look for malicious code or malicious websites on the network. Map each SC-35 determination statement to its own component, configuration and record, and cite those artifacts separately from SI-3 and SI-4 evidence so the assessor does not have to infer coverage.

Unchanged configuration for years

A detection rule set configured at deployment and never reviewed drifts away from the threats the system faces and from the way the system is used. Assessors look for evidence that configuration was reviewed, not only that it exists. Set a recurring review of rulesets, feed subscriptions and blocking actions, and record each change with its reason and approver. Keep dated exports of the configuration so the assessor can see how it changed across the assessment period.

Why SC-35 evidence is harder to show than most SC controls

SC-35 is harder to evidence than most SC controls because the organization, not NIST, has to decide what it covers. SC-35 has no SP 800-53B baseline, no organization-defined parameters and no control enhancements in Release 5.2.0. Many SC controls give an assessor a fixed set of parameters to check against, but SC-35 gives the assessor one determination statement: the organization must show that system components are deployed to proactively identify network-based malicious code or malicious websites. The scope of those components, and the traffic they watch, is therefore a decision the organization documents itself before any assessment begins.

That decision matters because the assessor's examine objects point at components that look outward. The SP 800-53A procedure asks for system components deployed for this purpose, system design documentation, configuration settings with their documentation, and audit records. An intrusion detection sensor on an external interface, a DNS filtering service or a sandbox that opens links will each produce some of that evidence, but only if the design document names it, the configuration shows it running against the right interfaces and the audit records show it acting. Confirm with your assessor early which outward-facing components they expect to see, since the procedure does not name products.

Five neighboring controls in the catalog overlap with SC-35: SC-7 (boundary protection), SC-26 (decoys), SC-44 (detonation chambers), SI-3 (malicious code protection) and SI-4 (system monitoring). Evidence for one often appears in another, such as firewall logs supporting SC-7 and sensor alerts supporting both SI-4 and SC-35. Document the boundary between them in the system security and privacy plan: state which component satisfies SC-35, which controls it also supports, and which traffic or system is excluded. Without that written boundary, an assessor may ask why a control was not claimed, or may find that the same log is cited as proof for three different requirements.

SC-35 questions buyers ask before hiring help

What does SC-35 work cost, and what drives the price up or down?

No supplied fact gives a price for SC-35 work, so treat any figure you see elsewhere with caution. The cost is driven by scope: how many network segments, sensors and log sources you want covered, how much existing logging you already have, and whether you pay for threat intelligence feeds. Feed licensing is often the recurring part, while setup and configuration are usually one-time. Ask any partner for a fixed-scope quote that lists each component to be deployed, each log source connected, each feed and its license terms, and which items are one-time versus recurring. DeployOpen plans and implements these systems in your environment and quotes from a written scope, so the scope list is the document to compare across bids.

How long does it take to implement SC-35 controls?

No supplied fact gives a duration, so confirm timing against your own environment. The timeline depends mainly on how many network boundaries and components must be instrumented, how mature your logging pipeline is, whether a SIEM or log store already exists, and how quickly your change approval process moves. Feed onboarding and tuning of alert thresholds often take longer than the initial sensor deployment, because someone must review false positives. Ask for a milestone plan that separates sensor deployment, log routing, feed integration, tuning and evidence capture, and agree on the dates in writing before work starts.

What does our team need to provide during an SC-35 engagement?

Expect your team to supply access, decisions and ownership. Typical inputs include:

Network diagrams and a list of boundary points where traffic enters and leaves the system
Administrative access to firewalls, the intrusion detection platform and log destinations, under your change control
A named owner who can approve alert actions such as blocking traffic
Decisions on which threat intelligence sources are acceptable under your policies and licenses
Time from security operations staff to review alerts and confirm tuning

The organization owns its controls. A partner prepares the systems, configuration and evidence, but your staff must operate and review them after handover.

Can we meet SC-35 with open-source tools alone?

Yes, the components that most often support SC-35 are open source, but whether they satisfy your assessor depends on design and evidence. OPNsense includes an intrusion detection and prevention system built on Suricata, which can use rulesets such as Emerging Threats and Abuse.ch and send alerts to syslog in EVE JSON format. Suricata's EVE output can record alerts, flows and protocol transactions such as DNS, HTTP and TLS. MISP can correlate indicators and export rules for Suricata, Snort and Zeek, while OpenCTI organizes threat intelligence and ingests feeds through connectors and TAXII. Open-source tools cover detection and intelligence well, but you still need a documented design, configuration records and reviewed alerts. Confirm each feed's license terms before you rely on it.

Is SC-35 required by FedRAMP or our own security baseline?

SC-35 is not required by FedRAMP's Rev5 baselines at Class B, C or D, and it is not assigned to any SP 800-53B baseline, including low, moderate and high. It applies only when your organization selects it through tailoring or an overlay, or when your contract, regulator or internal policy asks for it. Check your system's authorization package, any contract security schedule and your internal control catalog. If you are running a tailored program, record the decision and rationale in your system security plan so an assessor can see why SC-35 was selected or excluded.

Can an implementation partner issue an SC-35 assessment report?

No. An implementation partner prepares systems, configurations and evidence for SC-35, but only an independent assessor or auditor can issue an assessment report or attestation. DeployOpen implements, configures and documents self-hosted open-source platforms in your own infrastructure and prepares evidence for compliance assessments; it does not issue audit reports, attestations or certifications. Ask any partner to state this boundary in its statement of work, and ask your assessor which evidence types they expect for the SC-35 determination statement before implementation begins.

How DeployOpen prepares SC-35 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source components that can identify network-based malicious code and malicious websites inside your own infrastructure. We prepare the systems and evidence an assessor will examine, while your organization keeps ownership of the control decision, its risk acceptance and its operation.

How we scope

Confirm with you whether SC-35 is selected in your tailored baseline or overlay, since SP 800-53B does not assign it to any baseline.
Agree in writing which network segments, sensors and web-facing paths the SC-35 scope covers, along with the systems that produce its audit records.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support is available as a retainer.

How we build

Deploy and configure detection components such as an intrusion detection engine with malicious-code rulesets inside your cloud accounts, data centers or air-gapped networks.
Configure structured event output to your log management tools so that alerts on malicious websites and web-based malicious code are retained as reviewable records.
Connect threat intelligence platforms to the detection layer, then test that matching indicators produce alerts and that the configuration matches the documented design.

How we hand over

Document system design, configuration settings and their rationale, so an assessor can match them to the examine objects listed in SP 800-53A.
Provide sample audit records and alert traces that show the components operating, with the test results and the steps used to produce them.
Deliver a written record of open items, owners and dates for any gaps, so your organization can track them in its plan of action and milestones.

How we support

Review detection rulesets and threat intelligence feeds on a schedule agreed in the retainer, and record each change for later assessment.
Upgrade, back up and retest the SC-35 components after platform changes, so the evidence still reflects the running configuration.
Support your independent assessor's requests for system documentation and evidence, while the assessor alone determines the control's status.