What SC-48 sensor relocation asks your team to do
SC-48 requires your organization to relocate defined sensors and monitoring capabilities to defined locations under defined conditions or circumstances. The organization sets all three parameters: which sensors or monitoring capabilities move, where they can go, and what triggers a move. An assessor will not accept a control statement that leaves any of the three open, so the first task for a system owner is to write them down as organization-defined values in the system security and privacy plan, tied to the threats the system actually faces. The reason the control exists is that fixed monitoring is predictable. If an adversary learns that network sensors sit on the same segment span ports, or that host agents report from the same subnet, it can plan its activity to avoid them. Moving sensors breaks that map. In practice the hard parts are rarely the physical or virtual move itself. They are defining trigger conditions specific enough that someone can test whether they fired, keeping the record of where each sensor sits current across change cycles, and proving afterward that a relocation happened when and how the plan said it would.
For evidence, the SP 800-53A procedure looks for the list of sensors and monitoring capabilities to be relocated, change control records, configuration management records and system design documentation. Open-source network sensors can help here. For example, an illustrative deployment might run Suricata with its EVE JSON output, which records alerts and protocol transactions that can be split into separate files for a log management tool. A relocation then shows up as a change in the sensor configuration and in the sensor's own logs, which can be matched to the approved change ticket. Confirm with your assessor which records they expect and how far back they will sample. Because SP 800-53B does not place SC-48 in any baseline, most systems will only carry it if the organization selects it through tailoring or an overlay, and that choice should be documented with a reason. Ask your assessor and authorizing official whether it is in scope before you invest in relocation tooling, and confirm with your compliance lead whether any contract or regulator requires it. If it is selected, the monitoring design, the trigger definitions and the change records should be owned by named roles so the evidence stays current between assessments.
Which systems and sensors SC-48 reaches, and when it applies
SC-48 only reaches the systems an organization chooses to bring into scope, and it applies only after the organization selects it through tailoring or an overlay. The cards below cover the scoping decisions that change the work, from baseline status and FedRAMP treatment to the sensor types and parameters an assessor will expect to see defined.
Not in any SP 800-53B baseline
SP 800-53B does not assign SC-48 to the low, moderate, high or privacy baseline. The control applies only when the organization selects it through tailoring or an overlay. Appendix C of SP 800-53 lists it as implemented by the organization and the system (O/S), so the organization must decide who owns the sensors and who owns the relocation process. Record the selection and its rationale in the system security plan so an assessor can see that SC-48 was a deliberate choice rather than an omission.
FedRAMP Rev5 does not require it
The FedRAMP Rev5 baselines do not require SC-48 at Class B, C or D. Cloud providers and agencies pursuing FedRAMP authorization should not expect an assessor to test it by default. Confirm the current FedRAMP treatment in the control reference before planning the assessment, and document any voluntary adoption so that the authorization boundary and the evidence set stay consistent.
Three organization-defined parameters
In Release 5.2.0, SC-48 has three organization-defined parameters. The organization must define which sensors and monitoring capabilities are relocated, the locations they may move to, and the conditions or circumstances that trigger a move. Vague answers to any of these three leave the control untestable, so write each parameter as a specific list or rule that an assessor can compare against change records and system design documentation.
One enhancement to scope
SC-48 carries one control enhancement in Release 5.2.0. Decide whether the enhancement applies to the system before finalizing the control implementation statement, because an unselected enhancement still needs a documented rationale. Map the enhancement to the sensors that will be relocated so that each relocation rule has a named owner, a trigger and a record of the change.
Network sensors and boundary monitoring
Network sensors such as intrusion detection and prevention engines on firewalls or span ports are the most common candidates for relocation, since moving them changes what traffic an adversary can avoid. Open-source options such as OPNsense, which runs Suricata with alerting and blocking, can be inventoried as sensors. Confirm which interfaces, segments and sensor placements the organization is willing to change, and document the approved alternate locations in advance.
Host and log-based monitoring
Host agents, endpoint telemetry and log collectors form a second class of sensors. Suricata's EVE JSON output can route alert, flow, DNS, TLS and file records to separate files for log management tools, which makes the monitoring pipeline easier to inventory. Identify which host sensors and logging paths can be moved, and confirm that relocation does not break audit record generation covered by the AU family.
How an assessor tests SC-48 relocation
This table walks through the single SC-48 determination statement in SP 800-53A Release 5.2.0, the examine, interview and test methods an assessor applies to it, and the findings that most often appear. Read each row as one step of the assessment. The main takeaway is that an assessor needs three things to agree: defined triggers and locations, a change record for each move, and evidence that monitoring continued after the sensor moved.
| Assessment element | What the assessor does | Evidence that passes or fails |
|---|---|---|
| Determination statement | Decides whether the defined sensors, locations and conditions exist and whether relocations follow them. | Passes when parameters are filled in and each relocation matches them. Fails when parameters are blank in the security plan. |
| Examine: sensors and monitoring capabilities list | Reads the list of sensors designated for relocation and checks it against the deployed inventory. | Current list matches live sensors. Finding: the list names sensors that were retired or never deployed. |
| Examine: change control records | Samples relocation events and traces each to a request, approval and implementation record. | Approved tickets dated before the move. Finding: a sensor moved with no ticket. |
| Examine: configuration management records | Compares sensor configuration baselines before and after each move. | Versioned configurations showing updated addresses and identifiers. Finding: baselines never updated after a move. |
| Examine: system design documentation | Checks whether the architecture shows fixed monitoring points, alternate locations and the path for moving sensors. | Diagrams and monitoring design naming alternate locations. Finding: design describes no alternate locations. |
| Interview: staff who trigger relocations | Asks security operations and network staff who decides to move a sensor, what prompts the move and how coverage is checked afterward. | Answers match documented triggers and review steps. Finding: staff cite triggers that appear in no policy. |
| Test: confirm a relocation occurred | Illustrative: pick one recorded move, confirm the sensor reports from the new location and confirm capture continues afterward. | Sensor logs with timestamps before and after the move, such as Suricata EVE output. Finding: no capture after the move. |
| Common finding: undefined trigger conditions | Assessor cannot tell when relocation is required, so the control cannot be tested for consistency. | Ask for written trigger conditions tied to threat or risk inputs before the assessment begins. |
How to implement SC-48 in order
This sequence turns SC-48 from a parameter list into a working relocation capability: an agreed sensor inventory, approved destinations, documented triggers, a change path that every move must follow, and a rehearsed procedure that shows the move works before it is needed in production.
Define the sensors and monitoring capabilities in scope
Start by deciding which monitoring points SC-48 covers. The first organization-defined parameter asks for the sensors and monitoring capabilities that may be relocated, so the system owner and security operations lead should list each one, such as network sensors, host telemetry agents or log collectors, with its host, network segment and the monitoring function it supports. Record the list in a sensor register, with an owner for each entry. The step is done when every entry has a named owner and an agreed reason it can move, and when the list has been reviewed against the system boundary documentation.
Define the locations the sensors may move to
The second parameter names the defined locations a sensor may be relocated to. For each sensor in the register, the architecture team should identify candidate destinations that are already approved in the system design, such as alternate network segments, spare sensor hosts or other points on the monitored path, and confirm that each destination can receive the sensor's traffic or telemetry without weakening controls elsewhere. Document these destinations in the relocation runbook under a section that names the approved locations. The step is complete when the design documentation and the runbook match, and each sensor has at least one approved destination or an explicit note that it cannot be moved.
Define the conditions that trigger a move
The third parameter defines the conditions or circumstances under which relocation happens. Work with the security operations and threat intelligence teams to write specific, observable triggers, such as indicators of targeting against a sensor, detection gaps reported by a threat hunt, or a change in threat activity described in internal reporting. Each trigger should name who may authorize a move and what evidence must be recorded. Keep the trigger definitions in the same runbook as the destinations so an assessor can trace a relocation back to a documented condition. The step is done when each trigger is written, approved by the control owner, and linked to the sensors it affects.
Set the change control path for each relocation
Relocations change the monitoring configuration, so each move should pass through the organization's existing change control process rather than an ad hoc action. Create a change record template that captures the sensor, the trigger that justified the move, the origin and destination, the approver, the planned rollback and the verification results. Link the change process to configuration management records so the baseline stays accurate after each move. The step is complete when the template is approved, the change board knows the relocation category, and a sample change record can be traced from trigger to approval to post-move verification.
Test the move in a controlled environment
Before relying on relocation in production, rehearse it in a test or staging environment that mirrors the sensor configuration and the approved destinations. Run each runbook procedure, confirm that telemetry arrives at the new location in the expected format, check that alerting and log forwarding still work, and time the steps so the team knows what the process demands in practice. Record the results, the defects found and the fixes in the change records and the test report. For open-source sensors such as Suricata, check that alerts and EVE JSON output reach the log management tool after the move. The step is done when a test relocation has been completed, verified and rolled back successfully, and the results are filed as evidence for the assessor. Confirm with your independent assessor how much test evidence they expect for an unselected control.
Evidence that passes SC-48 and how to keep it current
An assessor testing SC-48 looks for records that tie each sensor relocation to a defined trigger, an approved change and a verified result. The cards below map to the examine objects in SP 800-53A and state how often each artifact should be refreshed between assessments and who owns it.
Defined sensor and location inventory
This is the list of sensors and monitoring capabilities the organization has defined as relocatable, with their current and permitted locations. It is the starting point for every SC-48 test because the assessor needs to see exactly what can move. Check that each entry names the sensor, its monitored segment and the locations it may occupy. Refresh it whenever a sensor is added, retired or moved, and at least at each assessment. The security architecture lead owns it, with the network operations team maintaining the entries.
Written relocation trigger conditions
The control requires relocation under defined conditions or circumstances, so the triggers must be written down before anyone needs them. Typical triggers in a procedure might include indicators of adversary reconnaissance against a monitored segment or a published threat that targets a known sensor placement. Each trigger should state who decides, what evidence starts the decision and what the maximum response time is. Review the list at least annually and after any significant incident. The security operations manager owns the triggers, and the CISO approves them.
Change control records for each move
Every relocation should pass through the normal change process, with a request, risk review, approval and a rollback plan. Assessors use these records to confirm that moves are authorized and not ad hoc. The record should link the trigger that justified the move to the approved change. Keep records for the full review period and reconcile them against sensor location changes in configuration records. The change advisory board chair owns the process, and the requesting engineer completes each entry.
Configuration records of the new placement
Configuration records show the sensor's new placement after each move, including interface assignments, mirror or tap ports, firewall rules and the monitoring policy that applies there. These records prove the sensor is where the change record says it is. Compare them against the defined inventory to catch sensors left in unapproved locations. Export or snapshot configurations after every change, and run a periodic comparison against the approved baseline. The network engineering team owns these records and the configuration management function checks them.
Updated system design documentation
System design documents, including network diagrams and monitoring architecture, must show where sensors sit after each relocation. An assessor compares these documents with the inventory and the configuration records to find gaps. Update diagrams within a defined period after each approved change, and review the full set at each assessment. Note that this document set also feeds the system security and privacy plan. The system owner is accountable for accuracy, and the architecture team maintains the diagrams.
Verification log after each move
After each relocation, the team should record a test showing that the sensor sees the intended traffic from its new location and that detection rules still fire. Open-source sensors such as Suricata write EVE JSON output that can confirm traffic visibility and alert generation after a move. Log the test date, the person who ran it, the result and any gap found. Failed checks should open a ticket and block closure of the change record until resolved. The security engineering team owns the log and reviews failures weekly.
What meeting SC-48 costs in money and effort
This table breaks down the cost components of running SC-48 Sensor relocation, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a written scope and to ask vendors and partners for line-item quotes, since no price or duration is published for this control.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | What to request in a quote |
|---|---|---|---|
| Sensor and monitoring tooling | Recurring if commercial licenses apply; one-time for hardware. Paid to the tool vendor or hardware supplier. | Number of sensors and sites in the defined set. Self-hosted open-source sensors such as Suricata remove license spend but still need hosts, storage and tuning. | Itemized license terms, hardware bill of materials, and whether support contracts are separate. |
| Engineering time to define parameters | One-time, with periodic review. Paid to internal staff or an implementation partner. | Number of organization-defined parameters (three in Release 5.2.0) and how many sensor types must be covered. | A written definition of relocation triggers, target locations and conditions, with named owners and review dates. |
| Runbooks and relocation procedures | One-time to build, recurring to maintain. Paid to internal staff or a partner. | Degree of automation. Manual relocation of sensors takes more operator hours per event than scripted or templated moves. | Draft runbooks for each defined condition, and a test or tabletop plan that proves each runbook works. |
| Change control per relocation | Recurring, one per move. Paid through internal change board time. | Frequency of threat-driven moves and whether existing change control already covers sensor configuration. | Confirmation that the change process records each move, approver and rollback step, and whether emergency changes have a fast path. |
| Evidence upkeep | Recurring. Paid to internal compliance staff or an assessment partner. | Volume of change records, configuration management records and design documentation the assessor will examine. | The evidence list tied to the examine objects in SP 800-53A, and the retention period for each record type. |
| Monitoring and log management | Recurring. Paid to the platform operator, a log platform vendor or internal staff. | Volume of EVE JSON output and the number of record types split into separate files for log tools. | Data volume estimates for the configured sensors, storage duration and the query tooling included. |
| External testing or review | Recurring or periodic. Paid to an independent tester or assessor. | Scope of the relocation logic, whether red team exercises test it, and how often the defined conditions change. | A fixed scope naming which relocation conditions are tested, and whether retesting after changes is included. |
| Auditor sampling | Recurring at each assessment. Paid to the independent assessor. | Whether SC-48 is in the selected baseline or tailored in, which determines if sampling covers it at all. | Confirmation from the assessor of whether SC-48 is in scope before fees are agreed. |
Using OPNsense and Suricata logs as sensor evidence
SC-48 asks an organization to move defined sensors to defined locations under defined conditions. The cards below cover two open-source tools that can generate records of what sensors saw and where they sat, and the boundary between that evidence and the relocation process the organization must still run and document.
OPNsense intrusion detection and prevention
OPNsense includes a built-in intrusion detection and prevention system that runs Suricata with rulesets such as Emerging Threats and Abuse.ch. Rules can alert on matching traffic or block it, and alerts can be sent to syslog in EVE JSON format. For SC-48, the firewall is a sensor whose placement must be recorded, so confirm which interfaces the IDS listens on, which rulesets are enabled, and whether each change to them passes through change control. Check the licensing terms of each ruleset in your own environment before relying on it.
Suricata EVE output as log evidence
Suricata's EVE output writes JSON records for rule alerts, anomalies, flows, protocol transactions such as HTTP, DNS, TLS, SSH and SMB, file information, dropped packets and engine statistics. Because EVE output can be split into separate files, teams can route each record type into a log management tool. An assessor testing SC-48 can use these records to see which traffic a sensor observed during a period, which helps show whether a relocation changed coverage. Confirm that your log pipeline keeps timestamps and sensor identifiers intact so records can be tied to a specific location and date.
Logs do not relocate sensors
These tools produce evidence, but they do not perform relocation. OPNsense and Suricata can show where a sensor was and what it saw, yet they do not decide when to move a sensor, select the new location or record the approval. The organization must define the sensors and conditions, run the relocation under change control and keep the design documents, configuration records and change tickets that an assessor will examine. Ask any implementation partner to state in writing which parts of SC-48 they prepare and which records remain the organization's responsibility.
Who owns SC-48: your team, a partner and the auditor
Your organization owns SC-48. Only your team can decide which sensors and monitoring capabilities are in scope, which conditions trigger relocation and where sensors may move. Those decisions carry the risk judgment, so they belong to accountable people in security and system ownership roles, and they must be documented in a way that an assessor can trace.
- Sensor list and triggers: Approve the defined sensors and monitoring capabilities and the organization-defined conditions or circumstances that start a relocation.
- Relocation decisions: Authorize each move, record who approved it and the reason, and confirm that the target locations are defined in advance.
- Change records: Keep change control and configuration management records for every relocation, since these are the records an assessor examines.
- System design documentation: Maintain the design documents that show where sensors sit and how relocation fits the architecture.
- Outsourcing limits: Partners can draft materials, but your team should sign off on the sensor list and triggers.
Before an assessment, confirm that someone in your organization can explain every relocation decision from the records alone.
An implementation partner prepares the systems, documentation and evidence that let your team meet SC-48. The partner does not decide what your risk appetite is and does not sign the control as met. Its work is preparation, and it stays inside the scope your organization approves in writing before work starts.
- Sensor register: Build a register of sensors and monitoring capabilities, with their locations, configurations and owners, for your team to approve.
- Runbooks: Draft relocation runbooks that follow your approved triggers and show the steps, approvals and rollback.
- OSCAL-style documentation: Prepare control documentation in a structured format, such as OSCAL-style content, so that records stay consistent and reusable.
- Sensor configuration: Configure open-source sensors, for example Suricata with EVE JSON output on OPNsense, so that alerts and logs can show what each sensor saw and where it ran.
- Evidence collection: Gather configuration exports, logs and change tickets that show relocations happened as approved.
Usually outsourced: the register, runbooks and configuration work. Not outsourced: approval of triggers and the decision to relocate. Ask any partner to show in writing which deliverables it prepares and which it leaves to your team.
An independent auditor or assessor tests SC-48 against the assessment procedure in SP 800-53A and issues the findings and report. Only the assessor can make that determination. Neither your team nor a partner that helped prepare the evidence can issue the report or stand in for the assessor's independence.
- Examination: The assessor examines the list of sensors, change control records, configuration management records and system design documentation.
- Interviews: The assessor interviews the people who approve and carry out relocations to confirm they understand the process.
- Testing: The assessor may test whether a relocation works as documented, within an agreed and safe test plan.
- Findings: The assessor records findings and the report, which only the assessor issues.
- Independence line: A partner that wrote the runbooks or configured the sensors should not perform the assessment of those same items.
Before engaging an assessor, confirm in writing how they handle independence, which evidence they will examine and who issues the final report.
Where SC-48 implementations usually fall short
SC-48 is short on paper but easy to implement loosely. Most gaps come from undefined parameters, records that do not match the live environment, and moves that bypass change control. The cards below pair each gap with a fix an assessor can check against the SP 800-53A examine objects.
Vague trigger conditions
SC-48 requires relocation under defined conditions, so an organization that never writes those conditions has no basis for any move. Define the threat indicators, monitoring findings or intelligence inputs that trigger relocation, and record who decides. Without this, every relocation looks arbitrary and no decision can be shown to follow policy. Check that each defined condition maps to a documented decision owner and a review record.
Sensors moved without change records
A sensor that changes location without a change record breaks the trail an assessor follows from the defined trigger to the new placement. Require a change ticket for every relocation that names the sensor, the origin, the destination, the trigger and the approver. Keep these records alongside configuration management records, since the SP 800-53A examine objects for SC-48 include change control records.
Sensor register out of sync
The sensor register is the list of monitoring capabilities the organization says it can relocate, and it must match the live configuration. Reconcile the register against sensor configurations, such as Suricata or OPNsense IDS interfaces and log forwarders, on a fixed schedule. Any sensor found running but missing from the register should be treated as a finding until it is documented.
Relocations handled as ad hoc work
When an engineer moves a sensor during an incident without opening a change, the move falls outside the approval and testing steps the organization defined. Route emergency relocations through an expedited change path that still records the trigger, the approver and a retrospective review within a period the organization sets. Confirm that the emergency path is written into the change procedure, not left to individual judgment.
No verification after a move
A relocated sensor that sees no traffic, or sees the wrong segment, gives false confidence while the threat moves elsewhere. After each move, confirm the sensor produces expected output, for example by checking EVE JSON alert and flow records arriving at the log platform from the new location. Record the test result against the change ticket so the assessor can trace the move to working monitoring.
Tailoring without documented rationale
SC-48 is not in any SP 800-53B baseline, so selecting it is a tailoring decision that needs a written reason. Record why the threat model justifies relocation, which sensors and locations are in scope, and which organization-defined parameters were set. Where the control is not selected, record that decision too, so the system security and privacy plan explains the absence rather than leaving it unexplained.
SC-48 questions buyers ask before hiring outside help
Is SC-48 sensor relocation harder to implement than other SC controls?
Usually it takes more design and governance effort than a typical SC control, because it requires defined sensors, defined relocation triggers and a documented process for moving them. Boundary protection (SC-7) or transmission encryption (SC-8) are configured once and then mostly monitored. SC-48 adds decisions about which monitoring points can move, what conditions justify a move, and how each move is approved, recorded and reversed. The effort depends on how many sensors are in scope and how mature the existing monitoring design is. Ask a prospective partner to size the work from a written list of sensors and triggers rather than from the control title alone.
Do I need SC-48 in my SP 800-53 baseline?
No. SP 800-53B does not assign SC-48 to the low, moderate, high or privacy baseline, so it applies only when your organization selects it through tailoring or an overlay. Selection usually follows from a documented risk assessment, a threat model that shows fixed monitoring points are being avoided, or a contract or authorizing body that asks for it. Appendix C of SP 800-53 lists the control as implemented by the organization and the system. Confirm with your authorizing official or contracting officer whether SC-48 is expected in your environment before you spend money on it. FedRAMP's Rev5 baselines also do not require it at Classes B, C or D.
What does SC-48 need from our own staff?
Your staff own the decisions, and an implementation partner can prepare the technical work and evidence. Internal owners need to define which sensors and monitoring capabilities are relocatable, the locations they may move to, and the conditions that trigger a move. Security operations staff need to confirm that alerting, log collection and analysis still work after each relocation. Change management staff need to route relocations through the normal change control process. Ask a partner to name the internal roles it expects to work with, the decisions it will not make on your behalf, and the review meetings needed to close each design decision.
How long does SC-48 implementation take?
The duration depends on scope, and no reliable figure applies across organizations. The main drivers are the number of sensors in scope, how many relocation locations and triggers you define, whether monitoring runs on hardware you control or on cloud services, and how many change control and testing cycles your process requires. A narrow scope covering a few sensors in one environment will move faster than a multi-site program with many triggers. Ask for a written schedule tied to a fixed scope, with milestones for design, testing, change approval and evidence collection, before work starts.
Can we implement SC-48 in-house with open-source tools?
Yes, in many environments the tooling is open source, but the control is a design and process requirement, so tools alone do not satisfy it. OPNsense includes an intrusion detection and prevention system that runs Suricata, and its alerts can be sent to syslog in EVE JSON format. Suricata's EVE output records alerts, flows, protocol transactions and engine statistics, and can be split into separate files for log management tools. These capabilities help you produce evidence of monitoring activity, but you must confirm for your own platform and version how sensor placement can be changed and logged. Your team must still define the relocation criteria and approval path.
What will an assessor ask for first on SC-48?
An assessor will start with the list of sensors and monitoring capabilities that the organization has defined for relocation, because SP 800-53A examines that list first. Next, expect requests for change control records, configuration management records and system design documentation showing how relocations are planned, approved and carried out. Assessors may also interview staff about the conditions that trigger a move and test whether a relocation actually occurs. Prepare these documents before the assessment window opens. An independent assessor issues the findings. An implementation partner can prepare the system, the records and the evidence, but it does not assess or certify the control.
How DeployOpen scopes and prepares SC-48 evidence
DeployOpen approaches SC-48 Sensor relocation as a fixed-scope piece of implementation work inside your own infrastructure. We prepare the sensor placement design, the relocation procedure and the records an assessor will examine, while your organization decides whether SC-48 belongs in your control set at all.
How we scope
- We confirm with you whether SC-48 is selected through tailoring or an overlay, since no SP 800-53B baseline includes it.
- We agree in writing which sensors and monitoring capabilities are in scope, and which defined locations and conditions trigger relocation.
- We record the defined parameters and the systems they touch, so the written scope matches what the assessor will test.
How we build
- We configure the sensing layer, such as an OPNsense intrusion detection deployment running Suricata, inside your own network or cloud accounts.
- We set up change control and configuration management records for each relocation so every move leaves a traceable entry.
- We test that relocated sensors still produce alerts and EVE JSON logs at the new location before the change is closed.
How we hand over
- We deliver the relocation procedure, sensor inventory, design documentation and configuration records mapped to the SC-48 examine objects in SP 800-53A.
- We document the test results for each relocation, including the monitoring checks run after the sensor moved.
- Your assessor, not DeployOpen, examines this evidence and issues any report or conclusion on SC-48.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- We can review relocation records during your continuous monitoring cycle, so evidence stays current between assessments.
- Before the engagement starts, ask us to confirm the deliverables, acceptance criteria and handover format in the written scope.
