SA-9: External System Services

Quick-reference card

What this control requires

SA-09 requires organizations to hold external service providers to defined security and privacy standards, document oversight responsibilities, and continuously monitor provider compliance. Most organizations rely on dozens of external providers for critical functions, yet few maintain the contractual and technical controls needed to verify that those providers meet security expectations.

In practice, SA-09 mandates three actions. First, you must specify the security and privacy controls that external service providers are required to implement, and those requirements must be documented in contracts, service-level agreements (SLAs), or interagency agreements. Second, you must define and document who within your organization is responsible for overseeing external services and what role end users play in that relationship. Third, you must establish and follow specific processes, methods, and techniques for monitoring whether external providers are complying with your controls on an ongoing basis.

The control exists because outsourcing a service doesn’t outsource the risk. Authorizing officials remain accountable for the risk introduced by any external system or service, regardless of who operates it. Without documented security requirements, clear roles, and active monitoring, an organization can’t demonstrate that its third-party risk management program has substance behind it. SA-09 creates the structure that transforms vendor relationships from trust-based assumptions into verifiable, defensible arrangements.

Why it matters

Third-party access remains one of the most exploited attack vectors in enterprise environments. Attackers know that vendors often hold privileged credentials to customer networks, and that the monitoring and segmentation controls governing that access are frequently weaker than those applied to internal users. When an organization grants a service provider network connectivity without specifying boundaries or monitoring activity, it creates a direct path from the vendor’s security posture to its own critical assets.

Target Corporation and Fazio Mechanical

In late 2013, attackers sent a phishing email to an employee at Fazio Mechanical Services, a Sharpsburg, Pennsylvania HVAC and refrigeration contractor. Fazio held remote network access credentials to Target Corporation’s systems for electronic billing and project management. The employee opened the email, and the attackers obtained Fazio’s credentials.

Target had granted this third-party vendor network access without segmenting that access from its cardholder data environment, as Krebs on Security reported. The US Senate “Kill Chain” analysis documented what happened next: using Fazio’s credentials, the attackers moved laterally from the vendor access point to Target’s point-of-sale (POS) infrastructure, installed BlackPOS memory-scraping malware on the majority of Target’s POS terminals, and over two weeks exfiltrated payment card data for approximately 40 million customers. Personal information for an additional 70 million individuals was also compromised.

The SA-09 failure was the absence of adequate oversight over what a third-party service provider could reach once connected. Target had granted Fazio a network connection without specifying which portions of the network were reachable, without requiring Fazio to meet Target’s security baseline, and without monitoring Fazio’s access activity. An HVAC contractor with billing access had no legitimate reason to reach payment card systems. A network segmentation policy aligned with SA-09 would have enforced that boundary. A 2017 multistate settlement with 47 states and the District of Columbia for $18.5 million, the largest multistate data breach settlement at the time, required Target to adopt a comprehensive information security program.

What attackers exploit

• Unscoped vendor access. Providers receive broad network credentials instead of access limited to the specific systems and data their service requires.
• Missing compliance verification. Organizations accept vendor self-attestation without independent evidence, allowing security gaps to go undetected.
• Absent SLA security requirements. Contracts define uptime and performance metrics but omit security controls, leaving no enforceable baseline for the provider’s security posture.
• No ongoing monitoring. Vendor access is reviewed during onboarding but never reassessed, so credential misuse or configuration drift goes unnoticed.
• Lateral movement from vendor footholds. Attackers compromise a lower-security vendor and pivot through unsegmented connections to reach high-value targets inside the customer’s environment.

How to implement

For your vendors

The most common SA-09 failure mode is treating vendor onboarding as the finish line. Organizations invest heavily in pre-contract due diligence but rarely sustain that rigor through the life of the relationship. Compliance degrades silently when no one monitors whether a provider’s controls remain effective after the agreement is signed.

Start by defining the security and privacy requirements your vendors must meet before you grant them access to your systems. These requirements should be explicit in contracts and SLAs, covering areas like encryption standards, access control configurations, incident notification timelines, and data handling obligations. A vendor risk assessment conducted before onboarding should validate that the provider can meet these requirements, not just claim to.

When building your security questionnaire, focus on questions that surface operational reality rather than policy intent. Ask providers to describe how they restrict administrative access to systems that process your data, what logging and monitoring they perform on sessions connecting to your environment, and how quickly they notify customers of a confirmed security incident. Request evidence beyond self-attestation: independent audit reports such as SOC 2 Type II, penetration test summaries scoped to the services they provide you, and documentation of their own third-party risk management program. If a vendor can’t produce a current SOC 2 report or equivalent independent assessment, that’s a red flag worth escalating.

Red flags during vendor assessment include providers who resist sharing audit documentation, those who can’t name the security framework they follow, vendors with no documented incident response procedure, and any provider who claims they’ve never experienced a security incident. Verification should go beyond questionnaires. Where possible, validate vendor claims through technical evidence: review their externally visible security posture, confirm that access credentials follow least-privilege principles, and verify that network segmentation prevents their access from reaching systems outside the scope of their service.

Ongoing monitoring is where SA-09 compliance lives or dies. Establish a review cadence, at minimum annually for lower-risk vendors and quarterly for those with access to sensitive systems or data. Each review should include updated compliance evidence, confirmation that access permissions remain appropriately scoped, and validation that SLA security requirements are being met. Document every review cycle. If a provider falls out of compliance, your contract should define remediation timelines and escalation procedures, including the option to terminate access if deficiencies aren’t resolved. The UpGuard Vendor Risk platform provides continuous monitoring of your vendor ecosystem, automating the ongoing compliance verification that SA-09 demands.

Evidence examples

Cross-framework mapping

Related controls

• SA-02 — Allocation of Resources: ensures adequate resources are budgeted for the security requirements that SA-09 mandates in external service agreements.
• SA-04 — Acquisition Process: governs how security requirements are included in procurement, directly feeding the contractual controls SA-09 requires for external providers.
• AC-20 — Use of External Systems: restricts how organizational users connect to and use systems outside the authorization boundary, complementing SA-09’s provider-side requirements.
• CA-03 — Information Exchange: defines the rules for information sharing between systems, including the external connections that SA-09 oversees.
• CP-02 — Contingency Plan: addresses continuity planning for operations that depend on external service providers covered by SA-09.
• IR-04 — Incident Handling: establishes incident response coordination with external providers, a key oversight function under SA-09.
• IR-07 — Incident Response Assistance: defines how external providers support the organization’s incident response, extending SA-09’s documented roles and responsibilities.
• PL-10 — Baseline Selection: determines which control baselines apply and informs the security requirements imposed on external providers under SA-09.
• PL-11 — Baseline Tailoring: allows organizations to adjust baselines for external provider environments where standard controls may need modification.
• PS-07 — External Personnel Security: manages the screening and oversight of individuals employed by external service providers, a personnel dimension of SA-09’s oversight mandate.

Frequently asked questions

What is NIST SP 800-53 SA-09?

SA-09 is the NIST SP 800-53 control that requires organizations to impose documented security and privacy requirements on external service providers, define oversight roles, and monitor provider compliance continuously. It applies across LOW, MODERATE, HIGH, and PRIVACY baselines, making it a universal requirement for any federal system or organization following the NIST framework. The control addresses the full lifecycle of external service relationships, from contractual security requirements and service-level agreements to ongoing compliance verification through defined processes and methods.

What happens if SA-09 is not implemented?

Without SA-09 controls, organizations lose visibility into whether external service providers meet their security expectations, creating unmonitored pathways into critical systems. The Target Corporation breach demonstrated this risk directly, where an HVAC vendor’s compromised credentials provided attackers with uncontrolled lateral access to POS systems. Regulatory consequences include audit findings, loss of authorization to operate, and potential enforcement actions. Supply chain risk management plans that lack SA-09’s documented oversight and monitoring requirements leave organizations unable to demonstrate due diligence to regulators or auditors.

How do you audit SA-09?

Auditing SA-09 starts with reviewing contracts, SLAs, and interagency agreements to verify that each one specifies the security and privacy controls external providers must implement. Auditors then examine the organization’s documentation of oversight roles, confirming that responsibilities are assigned and users understand their obligations regarding external services. The final and most critical audit step is verifying that the organization follows its documented processes, methods, and techniques for monitoring external provider compliance, including evidence of completed reviews, control assessment reports from providers, and records of remediation actions taken when deficiencies were identified.

How do you monitor third-party compliance with SA-09?

Effective monitoring requires a defined cadence of compliance reviews backed by independent evidence, not just vendor self-attestation. Organizations should collect updated control assessment results or audit reports from external providers at regular intervals, verify that access permissions remain scoped to the contracted service, and validate that SLA security requirements are being met. Automated vendor monitoring tools can supplement periodic reviews by providing continuous visibility into a provider’s external security posture, flagging changes that may indicate compliance drift between formal assessment cycles.