What SC-43 usage restrictions requires and why it is easy to miss
When an assessor or a contract pulls SC-43 into scope, the first surprise is that no SP 800-53B baseline selects it. SC-43 Usage Restrictions only applies when your organization or the authorizing official chooses it through tailoring or an overlay, so it often arrives late, from a customer questionnaire or a contract clause, rather than from the baseline you started with. The control asks you to define usage restrictions and implementation guidance for the system components you name, and to authorize, monitor and control how those components are used inside the system. Its purpose is to reduce the risk that a component people treat as routine, such as a mobile code type, a wireless interface, a removable device or a networked peripheral, becomes a path for misuse or data loss because nobody wrote down the allowed uses.
The control is easy to miss because the organization-defined parameter decides what the work is. In Release 5.2.0, SC-43 has one organization-defined parameter and no control enhancements, so the list of components, and the rules for each, come from your own risk decisions rather than from NIST. Before any tooling is chosen, the reader should confirm which components are in scope for the system under assessment, who approves each usage rule, and where the rules are recorded. Related controls such as AC-18 on wireless access, AC-19 on mobile devices, CM-6 on configuration settings and SC-18 on mobile code often carry the enforcement, so SC-43 is best scoped alongside them rather than in isolation.
SP 800-53A Rev. 5 assesses SC-43 through four determination statements, using examine, interview and test methods. The examine objects named for this control include the usage restrictions themselves, authorization records, system monitoring records and system audit records, so an assessor will ask for the written rules, the record of who was authorized to use each component, and evidence that use is actually being monitored. Ask your assessor early which determination statements apply to your defined components, and confirm the monitoring and audit sources you intend to show. Your own environment, not the baseline, sets how much evidence is enough.
Which components and teams fall under SC-43 scope
SC-43 has no SP 800-53B baseline, so it reaches a system only when the organization selects it through tailoring or an overlay. The work starts with deciding which component types are in scope and which teams own them, because those choices set the size of the job.
Mobile code and downloadable scripts
The organization must define which mobile code, such as scripts, macros and similar downloadable code, is allowed and how each type is authorized and monitored. Scope usually covers browser-delivered scripts, office macros and plug-in runtimes. Check which applications run code fetched from outside the boundary, and who approves each runtime. Overlap with SC-18 Mobile code means one list of allowed code types should serve both controls.
Mobile and portable devices
Laptops, tablets and phones that connect to organizational systems are common SC-43 components when the organization defines them as such. Scope the device classes, the usage rules for each, and the owner who approves exceptions. Confirm whether the same devices are already covered by AC-19 access control for mobile devices, so the usage rules and the access rules are written once and cross-referenced.
Wireless access points and clients
Wireless networks are a usage question as much as a boundary question. Define which wireless technologies are permitted, which networks are authorized for organizational use, and who may connect new access points. AC-18 Wireless access and SC-7 Boundary protection carry much of the same content, so the component inventory and the rule set should be shared between the owners of those controls.
Printers, scanners and peripherals
Networked printers, multifunction devices and scanners store and transmit documents, and they are often managed by facilities or vendors rather than IT. Decide which peripherals are in scope, what they may be used for, and who authorizes them to connect. Check whether these devices also appear in the configuration baseline maintained under CM-6, since an unmanaged printer is a common gap between the two controls.
Configuration baselines and inventories
Usage rules are only enforceable when the organization knows which components exist. Confirm that the inventory covers every defined component type and that each entry names an owner. The CM-6 configuration settings and the component inventory are the natural evidence source, so an assessor will often ask to see them alongside the usage rules.
Tailoring and overlay decisions
Because SP 800-53B assigns SC-43 to no baseline, the first scoping decision is whether the system selects it at all. Record the tailoring decision, the rationale and the owner who accepted the risk of leaving it out. If an overlay for the system type already includes SC-43, that selection governs. Confirm the decision with the authorizing official or the body that owns the compliance program, since the choice is theirs to approve.
How an assessor tests SC-43 with examine, interview and test methods
The examine method has the assessor read documents, records and configurations against the four determination statements for SC-43. SP 800-53A Release 5.2.0 lists several examine objects for this control: usage restriction documents, authorization records, system monitoring records and system audit records. Each object answers a different question. The restriction documents show what is allowed, the authorization records show who approved the use of a component, and the monitoring and audit records show whether the organization watches the use.
- Usage restriction documents: Written rules for each defined component type, such as mobile code, wireless access, mobile devices or peripherals, along with implementation guidance.
- Authorization records: Approvals showing that a specific component or use was authorized before it was placed in service.
- System monitoring records: Logs or reports showing that use of the component is observed over time, not only at configuration time.
- System audit records: Entries that show restricted actions were captured, so an assessor can trace attempted or completed uses.
- Scope match: Documents that name the components defined in the organization-defined parameter, so the assessor can confirm nothing in scope is missing.
Before an assessment, confirm that each examine object exists, is current and names the same components as the system security plan. Ask the assessor which objects they plan to sample.
The interview method tests whether people who run and use the system know the restrictions and act on them. SP 800-53A pairs interviews with the examine and test methods so that statements in documents can be checked against practice. Assessors usually interview system owners, security staff, system administrators and a sample of end users, and they compare the answers with what the documents say.
- Owners and approvers: Who authorizes use of a component, how exceptions are requested and who reviews them.
- Administrators: How restrictions are configured, what happens when a new device type appears and who is told when a restriction changes.
- Monitoring staff: What they watch for, how often they review it and how they respond to a violation.
- End users: Whether they know which mobile code, devices or peripherals are permitted and how to request an exception.
- Consistency checks: Whether answers across roles match each other and the written procedures.
Prepare short, role-specific briefings so interviewees can answer accurately. Confirm that staff can point to the documents they rely on, because an interviewee who cannot find the rule is treated as a gap even when the rule exists.
The test method asks whether the restrictions work when the system runs. The assessor tries to use a restricted component or action and records whether the system permits, blocks, logs or alerts on it. This is the method that separates a policy from an enforced control. Testing usually covers a sample of components from the defined list, using the organization's own configuration and tooling where possible.
- Enforcement tests: Attempts to run restricted mobile code, connect an unauthorized device or use a disallowed wireless network, with the result recorded.
- Configuration checks: Review of live settings, such as allowlists, device policies or peripheral controls, against the documented rules.
- Monitoring tests: Confirmation that a test violation produces a log entry or alert that reaches the responsible team.
- Exception handling: Confirmation that an approved exception works as recorded and expires or is reviewed as the authorization says.
- Repeatability: Test results that the organization can rerun, so the same outcome appears on later assessments.
Ask the assessor which components they intend to test, and confirm that your test environment mirrors production. Confirm that test evidence is captured with timestamps and identifiers.
Assessors regularly report the same gaps for usage restriction controls. The most frequent is a restriction that is written and approved but never enforced. The document says mobile code is limited, yet no control stops an unlisted script from running. Another is a restriction that covers only some components, often the ones the security team thought about first, while peripherals, wireless adapters or newer device types are left out.
- Written but not enforced: Policy text with no matching configuration, allowlist or technical block.
- Incomplete component list: The organization-defined parameter omits components that are present in the system.
- Missing authorization records: Components in use with no approval on file, or approvals that do not name the component.
- Monitoring without review: Logs collected but no evidence that anyone reviews them or acts on violations.
- Stale documents: Restriction rules that no longer match the current architecture, with no record of review.
Before the assessment, walk through each finding category against your own system and confirm which ones you can disprove with evidence. Treat any gap you find as a plan of action item rather than an open question for the assessor.
Implementing SC-43 one defined component at a time
This sequence turns SC-43 from a policy statement into a set of component-specific usage rules that an assessor can trace from the organization-defined parameter through to monitoring records. Each step names what the organization or its implementation partner produces, so the assessor can see how the rules were chosen, approved and checked.
Confirm SC-43 is in scope
Start by checking whether SC-43 applies at all. SP 800-53B does not place it in any security baseline, so it enters the plan only when the organization selects it through tailoring or an overlay, or when a contract, FedRAMP package or internal policy requires it. The system owner records the selection and the reason for it in the system security and privacy plan. Done means the control appears in the plan with its tailoring rationale, so nobody later wonders why it is missing or present.
Define the components the parameter covers
SC-43 has one organization-defined parameter, which sets the list of system components that need usage restrictions. The system owner works with architecture and security staff to list them, for example mobile code runtimes, wireless access points, mobile devices, and peripherals such as printers and scanners. Each entry should match an item in the system component inventory so the list can be checked against real assets. Done means the parameter is written as a named list that an assessor can compare with the inventory.
Write usage restrictions and implementation guidance
For each listed component, the organization writes the restrictions on how it may be used and the implementation guidance that staff and administrators follow. A restriction might state which code types may run, which wireless networks may connect, or which peripherals may be attached. The guidance explains how to configure the component to meet the restriction. Done means each component has one restriction set and one guidance document, both approved by the owner and linked to the configuration baseline.
Assign authorization for each component use
The restrictions must say who may authorize a use of each component, and the authorization must be recorded. The organization assigns an approver for each component class, sets how requests are logged, and decides what happens when a use is denied or later revoked. Records typically name the requester, the component, the approver, the date and the scope of the approval. Done means an assessor can pick any authorized use and find its approval record.
Configure monitoring and enforcement
Next, the team configures the controls that enforce the restrictions and detect drift. Open-source tools can help here: Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, and custom policies can test for component settings the restrictions require. Fleet policies, written as osquery queries, can ask yes or no questions about devices such as whether a prohibited runtime is present. Done means each restriction maps to at least one check that runs on a schedule and reports pass or fail results.
Collect audit records of component use
The organization must show that it monitors use of the components, so the monitoring output needs to be retained as audit records. The team confirms that logs from endpoints, network devices and management systems reach the central log store, and that the records include who used which component and when. Where forensic collection is needed, Velociraptor hunts can gather artifacts from a group of systems and keep the combined results for analysis. Done means a sample of component use can be traced from the authorization record to the audit event that matches it.
Review and update the restrictions
Restrictions and their checks go stale as components change, so the organization schedules a review and records each result. The reviewer compares the component list with the current inventory, checks failed policies and unauthorized use findings, and decides whether restrictions need revision. Changes flow back into the configuration baseline and the system security and privacy plan. Done means the review record shows the date, the reviewer, the findings and the resulting changes, which the assessor can compare against the SC-43 determination statements.
Evidence that passes an SC-43 assessment
An assessor testing SC-43 looks for a documented set of usage restrictions, proof that someone authorized each use, and records showing the restrictions are monitored and enforced. The cards below cover the artifacts that carry that proof and how each one stays current between assessments through change management.
Usage restriction and implementation guidance
This is the written rule set for each defined component, such as mobile code, mobile devices, wireless access, and printers or scanners. Each entry should name the component, the permitted uses, the prohibited uses, and the implementation guidance staff follow. Assessors check that the document covers every component the organization has defined as in scope, so confirm the list matches the parameter value chosen for SC-43. Review it whenever a new component type is added.
Authorization records for each component
Authorization records show who approved a specific use of a component, when, and under what conditions. For mobile code, that might be a signed approval for a script runtime. For wireless or peripheral use, it is a request and sign-off tied to a device or location. Keep the approver, date, scope and expiry for each record. Assessors often sample these records against live configurations, so stale approvals for retired devices are a common finding.
Configuration baselines for restricted components
Baseline configurations translate the written restrictions into settings: which browser script policies apply, which wireless profiles are permitted, and which peripheral classes are enabled. Export these baselines from the systems themselves, not from the policy text, so the assessor can compare them directly. Store each baseline version with its approval, and record when a deviation was granted and reversed.
Endpoint compliance query results
Fleet policies and osquery queries can show, per device, whether mobile devices, wireless adapters or removable media match the approved restriction. Keep dated exports of passing and failing results, along with the query text that produced them. This is evidence that restrictions are monitored, not just written. Confirm with the tool's documentation how results are retained and exported in your environment before you rely on them.
Monitoring and audit logs of component use
Audit logs and monitoring records show that use of restricted components is observed and that violations generate alerts. Collect logs of mobile code execution, wireless association events and peripheral connections in a central store. Check that timestamps are synchronized so events can be correlated during review. Assessors usually ask for a sample of events and the alert that followed each one.
Periodic review and change-tied updates
Review records show that someone compared authorizations, baselines and monitoring results against the usage restrictions at a set interval, and recorded the findings. Tie each artifact to change management: a new wireless network, device model or script runtime should trigger an update to the restriction document, the authorization records and the baseline before the change is approved. Keep the review minutes, the actions raised and their closure dates together.
What meeting SC-43 costs in money and effort
This table breaks down the cost and effort components of meeting SC-43 Usage restrictions, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none are published for this control; use the questions in the final column to request comparable quotes. Open-source tooling removes license spend but not the labor to configure and evidence it.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Usage restriction authoring | Internal policy owners, with optional outside advisory support | One-time, then reviewed on change | Number of defined component types (mobile code, wireless, peripherals). Ask for the list of components in scope and the authoring hours assumed. |
| Enforcement engineering | Platform engineers or a DeployOpen-style implementation partner | One-time build, recurring changes | Number of platforms and enforcement points, such as endpoint policy, browser controls and network rules. Ask for a fixed-scope breakdown by component. |
| Monitoring configuration | Security engineers, including tooling staff | One-time setup, recurring tuning | Number of endpoints and whether monitoring feeds existing SIEM or audit pipelines. Ask how alerts for unauthorized use are routed and reviewed. |
| Open-source tooling licenses | Usually no license fee for the tools themselves | Recurring hosting and maintenance only | Hosting footprint and upgrade cadence. Open-source tools remove license spend but not labor. Ask who patches and operates the stack. |
| Evidence upkeep | Compliance leads and control owners | Recurring | Frequency of assessments and number of authorization records. Ask how usage approvals, monitoring reports and exceptions are stored and refreshed. |
| External review | Independent assessors, consultants or internal audit | Recurring per assessment cycle | Scope of the assessment and whether SC-43 is selected in the system baseline or an overlay. Ask whether the review covers policy only or operating evidence too. |
| Assessor sampling | Independent assessor (examination and interview of records) | Recurring per assessment cycle | Sample sizes the assessor selects from usage approvals and monitoring records. Ask the auditor how samples are drawn before scoping begins. |
Who owns SC-43 and what partners can take off your hands
Your organization owns SC-43. Only you can decide which components need usage restrictions, what those restrictions say, who may authorize use and which residual risk leadership accepts. SP 800-53 expects the organization and the system to share this control (listed as O/S in Appendix C), so the policy decisions cannot be handed to a vendor or consultant. Because SP 800-53B does not assign SC-43 to any baseline, your team must also document why it was selected, either through tailoring or an overlay.
- Scope decisions: choose the defined components, such as mobile code, mobile devices, wireless access, printers and scanners, and record why each is in or out of scope.
- Usage rules and implementation guidance: write the restrictions and the guidelines staff follow, and assign an accountable owner for each.
- Authorizations: approve who may use each component and keep the authorization records an assessor will examine.
- Monitoring responsibility: name the team that reviews monitoring output and the escalation path for violations.
- Risk acceptance: document exceptions and sign off on residual risk with a named authority.
Check that every decision in your policy has a named owner and a dated record before any partner begins configuration work.
An implementation partner prepares the systems and evidence that support your decisions. DeployOpen, for example, plans, configures and documents self-hosted open-source platforms inside your own infrastructure. A partner does not set your usage rules, approve users or accept risk, and it does not issue an assessment report, attestation or certificate. Those remain with you and with your independent assessor.
- Configuration: implement the restrictions you approved on the in-scope components, including the baseline settings that align with your CM family decisions.
- Monitoring: deploy and tune tools that report whether devices and components comply with the usage rules, such as configuration assessment or osquery-based policy checks.
- Evidence collection: set up the logs, query results and records that show restrictions are in place and monitored, in a form your assessor can examine.
- Documentation: prepare runbooks and the system documentation that explain how each restriction works.
- Handover: train your staff to operate the tooling and review its output without the partner.
Ask any partner to state in writing which deliverables it prepares and confirm that your team retains every approval and risk decision.
Independence starts where the assessor's testing begins. An assessor, auditor or certification body follows the assessment procedures in SP 800-53A. For SC-43 those procedures include examining your usage restrictions, authorization records, system monitoring records and system audit records, interviewing the people who run them, and testing whether the restrictions work in practice. The assessor reports findings on its own authority.
- Examination: the assessor reviews the documents and records your team produced, not the summaries a partner wrote about them.
- Interviews: staff explain how restrictions are applied and what happens when someone breaks them.
- Testing: the assessor may attempt to use a restricted component to see whether the control holds.
- Findings: the assessor reports gaps and their severity, and you decide how to remediate them.
- Limits on help: an assessor may not design the controls it tests without impairing its independence, so plan that separation in the engagement terms.
Before engaging anyone, confirm with the assessor how it will separate advisory work from testing.
Common SC-43 gaps and how to close them
SC-43 fails most often at the seams between policy and practice: a rule exists but names nothing specific, or nobody can show who approved a use. The cards below cover the gaps assessors meet most often, each with a closing action an organization can check against its own environment.
Restrictions tied to no named component
A usage rule that says mobile devices or wireless access are restricted does not tell an assessor what the rule covers. SC-43 requires the organization to define the system components in scope, so each restriction should name the component, its owner and the system it belongs to. Check that every restriction in the register maps to an inventory entry. Restrictions with no matching inventory record are the first gap to close.
No authorization records for use
SC-43 expects the organization to authorize use of the defined components, and an assessor will look for records showing who approved a given use and when. Many programs have written rules but no approval trail, so the examine step ends with nothing to inspect. Close the gap by defining a short approval workflow with a named approver, a request form and a retained record for each authorized use.
Monitoring that misses defined components
Monitoring is only evidence if it reaches the components the restrictions cover. An endpoint agent on laptops does not show whether wireless adapters or removable peripherals on shared kiosks are being used within the rules. Compare the monitored asset list against the component list and document any gap. Osquery can answer host-level questions across a fleet, and Wazuh can check configurations against the policies you define.
Peripheral policies that exist only on paper
Printers, scanners and USB devices are often covered by a policy document that no system enforces. An assessor who asks how a scanner is restricted and receives only a policy PDF will record a finding. Test each peripheral rule on a sample device and capture the result. Fleet policies can ask yes or no questions of each device and show which ones pass or fail, which turns a written rule into checkable evidence.
Undefined ownership of restrictions
When no one owns a usage restriction, nobody reviews it, updates it after a change or answers the assessor's questions. Each restriction should have a named owner who approves exceptions, reviews the rule on a set schedule and signs off on monitoring results. Record ownership in the same register as the component list, so the owner, the component and the authorization record can be read together. Confirm the review frequency with your own policy owner.
Mobile code rules outside the SC-43 scope
Scripts and macros are often governed under SC-18 while SC-43 is left blank, which leaves the usage rules for mobile code undocumented in the SC-43 record. Cross-reference the two controls so that the same component appears in both places with its authorization and monitoring evidence. The related controls for SC-43 include AC-18, AC-19, CM-6, SC-7 and SC-18, so review each of them when you map ownership and records.
SC-43 questions buyers ask before bringing in help
Is SC-43 required in a moderate baseline?
No. SP 800-53B does not assign SC-43 to the low, moderate or high baseline, so it applies only when your organization selects it through tailoring or an overlay. Your authorizing official or contract owner decides whether it belongs in your system's control set, and that decision should be written into the system security and privacy plan with a reason. Some frameworks you may be working under, including the FedRAMP Rev5 baselines in the current consolidated rules, do not require SC-43 at the classes they define. Confirm the requirement against the exact baseline, contract clause or regulator letter that applies to you before you scope any work, because a control that is absent from the baseline can still be requested by a specific agreement.
How much effort does SC-43 take to implement?
The effort depends on how many component types you need to restrict and how much of that restriction already exists in other controls. SC-43 asks you to define usage restrictions and implementation guidance for selected components, then authorize, monitor and control their use. Most of the work is documentation and decisions: naming the components in scope, writing the rules, and recording who is authorized. The technical part is smaller when mobile code, wireless access and peripheral rules are already enforced through configuration baselines and endpoint policies. Effort rises when the component list is long, when devices are unmanaged, or when monitoring records do not exist yet. Ask a partner to break the estimate into documentation, configuration, monitoring and evidence collection so you can see which parts you would carry internally.
What does the work need from our internal team?
Internal staff must make the decisions that an outside party cannot make for you. You will need a named owner for each component class, security and IT staff who can state which mobile code, wireless networks, mobile devices and peripherals are business-approved, and a change owner who can approve exceptions. Engineers should be available to confirm how endpoints, network access points and printers are actually managed today. Expect your compliance lead to review the written usage restrictions against your system security plan, and your auditor to request authorization records and monitoring output. Ask any partner to list these internal inputs in the statement of work so responsibilities are clear before work starts.
Can we implement SC-43 ourselves without outside help?
Yes, many organizations do. The control is organizational as much as technical, and an internal team that already runs configuration management, endpoint management and access control can write the usage restrictions, set up authorization records and collect monitoring evidence. Outside help is most useful when the team lacks time, when the restrictions must be applied across mixed fleets, or when the evidence must be produced in a repeatable form for an assessment. Whatever route you choose, the organization owns the control and the decisions. An implementation partner can prepare systems and evidence, but only an independent assessor issues an assessment result. Make that split explicit in any engagement letter.
How long does SC-43 implementation take?
No implementation duration for SC-43 is established in the supporting material for this page, so any timeline you hear should be checked against your own environment. The main drivers are the number of component types in scope, the state of current endpoint and network management, the number of approval workflows, and how many systems share the same restrictions. Organizations with existing configuration baselines and device inventories generally move faster than those building them from scratch. Ask a prospective partner to tie each phase of the timeline to a deliverable and to name the dependencies, such as access to test devices, change windows and reviewer availability. A written schedule agreed before work starts is more useful than a general estimate.
Which monitoring tools can produce SC-43 evidence?
Several open-source tools can show whether usage restrictions are enforced on endpoints, which is the kind of monitoring evidence an assessor looks for. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail each policy. osquery exposes running processes, open network connections and hardware events as SQL tables, and osqueryd can schedule queries across a fleet. Velociraptor can collect artifacts from many endpoints in hunts and keep the results for analysis. Confirm that each tool covers your specific component types, such as mobile code handling or peripheral connections, before relying on it as primary evidence.
What should we ask a partner for in a fixed-scope quote?
A fixed-scope quote should state the exact outcome, not just the activity. Ask the partner to list the component classes in scope, such as mobile code, mobile devices, wireless access and peripherals like printers and scanners, and to name the systems each class touches. The quote should itemize deliverables: usage restriction and implementation guidance documents, configuration changes, authorization record templates, monitoring rules and an evidence package mapped to the assessment procedure for SC-43. It should separate one-time work from recurring support, state what internal inputs are assumed, and say how changes to scope are priced. DeployOpen agrees scope, deliverables and timelines in writing before work starts and provides a quote from that written scope, and independent auditors remain responsible for any assessment result.
Does SC-43 overlap with other controls we already run?
Yes, and that overlap can reduce both cost and effort. The catalog relates SC-43 to AC-18 on wireless access, AC-19 on mobile devices, CM-6 on configuration settings, SC-7 on boundary protection and SC-18 on mobile code. If those controls already have documented settings and monitoring, you may be able to point SC-43 at the same records rather than building a separate set. Be careful with that reuse: SC-43 still needs its own usage restrictions, authorization and monitoring statements, and an assessor will check that each one is met. Ask your partner to produce a traceability table showing which evidence satisfies more than one control and which evidence is unique to SC-43.
How DeployOpen prepares SC-43 systems and evidence
DeployOpen works on SC-43 Usage restrictions by preparing the systems, usage rules and evidence that your organization and an independent assessor need to review. We implement open-source platforms inside your own infrastructure, and your organization owns the usage restrictions it adopts. DeployOpen does not issue assessment reports or certifications.
How we scope
- We confirm which mobile code, mobile devices, wireless access points and peripherals fall inside the SC-43 boundary.
- We agree which usage restriction rules your organization owns and which system components they govern.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure endpoint policy checks such as Fleet policies and Wazuh configuration assessments to monitor component use.
- We deploy osquery to report running processes, open connections and hardware events across the fleet.
- We set up Velociraptor artifacts that collect evidence from endpoints that were offline when a check ran.
How we hand over
- We document each restriction, its authorization record and the monitoring that shows it is enforced.
- We map SC-43 evidence to the four determination statements in SP 800-53A for your assessor to examine.
- We deliver configuration files, runbooks and reports in your environment, so your team can rerun them.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can review monitoring output and update policies when your approved component list changes.
- Confirm with your assessor which evidence formats and sampling periods they will accept before we build.
