Category: Security Controls & Tailoring

Customer-Configured Controls

Also known as: Customer Responsibility Controls, Customer-Provided Controls

Simply put

Customer-configured controls are security measures in a cloud service that the customer, rather than the cloud provider, must set up and manage. When an organization uses a cloud service, some protections come built in from the provider, but others depend on how the customer configures and operates the system. Understanding which controls fall to the customer is important because responsibility for those protections rests with the organization using the service.

Formal definition

In a cloud authorization context, customer-configured controls are those security controls whose implementation depends on configuration, provisioning, or operational actions performed by the customer (the consuming organization) rather than being fully inherited from the cloud service provider (CSP). In FedRAMP practice, such controls are generally documented in the System Security Plan (SSP) under a designated 'Customer Responsibility' heading within the control implementation description, distinguishing them from controls fully provided by the CSP and from shared controls where responsibility is divided. This concept is related to but distinct from configuration control, which is the broader process for managing and approving modifications to hardware, firmware, software, and documentation. Note that the specific allocation of responsibility varies by service model and offering and should be verified against the applicable Customer Responsibility Matrix or SSP; identifying a control as customer-configured does not by itself establish that the customer has correctly implemented it, and organizations remain accountable for assessing and maintaining these controls as part of continuous monitoring.

Why it matters

In cloud environments, security responsibility is divided between the cloud service provider (CSP) and the customer, and the boundary between the two is a frequent source of misunderstanding. When a customer treats a cloud service as fully secured by the provider, controls that actually depend on customer configuration can be left unimplemented or misconfigured. Because responsibility for those protections rests with the consuming organization, a gap in customer-configured controls becomes the organization's exposure, not the provider's.

For systems undergoing authorization, this distinction is not merely operational but documentary. In FedRAMP practice, customer-configured controls are generally captured in the System Security Plan under a designated 'Customer Responsibility' heading, separating them from controls fully provided by the CSP and from shared controls where responsibility is divided. Failing to identify and document which controls fall to the customer can leave assessors and authorizing officials without an accurate picture of the true security posture, and can undermine the basis on which an authorization decision is made.

A critical point that experts emphasize is that identifying a control as customer-configured does not, by itself, establish that the customer has correctly implemented it. The customer remains accountable for assessing and maintaining these controls, including as part of continuous monitoring. Compliance with a documented responsibility matrix is not the same as an effective, correctly operating control, and an authorization is time-bound and subject to ongoing verification rather than a permanent guarantee of security.

Who it's relevant to

Information System Security Managers and System Owners

These practitioners must identify which controls fall to their organization when adopting a cloud service and ensure those customer-configured controls are actually implemented and maintained. Relying on a provider's authorization without confirming customer responsibilities can leave controls unaddressed. They should consult the applicable Customer Responsibility Matrix or SSP to confirm the current allocation for their specific offering.

Assessors and Auditors

Assessors need to distinguish customer-configured controls from provider-inherited and shared controls to evaluate the correct party's implementation. Because documentation of a control as a customer responsibility does not confirm it has been correctly implemented, assessors must verify the actual configuration and operation rather than accepting the responsibility designation alone.

Authorizing Officials

Authorizing officials rely on the SSP's allocation of responsibility to understand where accountability rests for each control. They should treat the resulting authorization as time-bound and subject to continuous monitoring, recognizing that customer-configured controls remain the consuming organization's ongoing responsibility to assess and maintain.

Compliance Officers and Government Contractors

Organizations consuming cloud services under federal requirements must understand that a provider's authorization does not automatically satisfy their own obligations for customer-configured controls. Compliance teams should map documented customer responsibilities against their actual practices and verify details against current authoritative sources, since responsibility allocation varies by service model and offering.

Inside Customer-Configured Controls

Customer Responsibility Matrix (CRM)

A document, commonly provided by cloud service providers in FedRAMP and similar authorizations, that allocates control implementation responsibility between the provider and the customer. Customer-configured controls are typically those the matrix assigns wholly or partially to the customer to implement, configure, or maintain.

Shared responsibility allocation

The underlying model that distinguishes controls fully inherited from a provider, controls fully owned by the customer, and hybrid or shared controls. Customer-configured controls generally fall into the customer-owned or shared categories, where the provider offers a capability but the customer must enable and configure it correctly.

Configuration settings and parameters

The specific technical or administrative settings the customer must establish, such as access control policies, encryption options, logging levels, or authentication requirements. The available options are constrained by what the provider or platform exposes, and correct values generally depend on the applicable baseline and organizational tailoring.

Customer-side implementation evidence

Artifacts demonstrating that customer-configured controls have been implemented as intended, such as configuration exports, policy documents, and screenshots. This evidence is generally required to support the customer's own assessment and authorization, separate from the provider's authorization package.

Common questions

Answers to the questions practitioners most commonly ask about Customer-Configured Controls.

If my cloud service provider is FedRAMP authorized, does that mean the customer-configured controls are already handled for me?

No. A FedRAMP authorization generally covers the controls that the cloud service provider (CSP) implements and maintains within its service offering, but it does not cover controls designated as customer responsibility. Customer-configured controls are, by definition, those that the consuming organization must implement, configure, or manage within its own use of the service. Relying on a CSP's authorization while leaving customer-responsible controls unaddressed is a common gap that assessors flag. You should confirm the exact division of responsibility against the CSP's most current documentation, such as its shared responsibility matrix or customer responsibility matrix, rather than assuming inheritance.

Does inheriting controls from a provider mean I am compliant and secure for those areas?

Not necessarily. Inheritance addresses who is responsible for implementing a control, but compliance is not the same as security, and inheritance does not eliminate the customer's residual obligations. Even for inherited controls, your organization typically retains responsibility for verifying that the inherited implementation meets your applicable baseline, documenting the inheritance in your system security plan, and monitoring that the arrangement remains valid. Customer-configured controls specifically remain your responsibility to implement and assess. Treating any control as fully resolved simply because a provider is involved is a frequent misconception that experts caution against.

How should customer-configured controls be documented in a system security plan?

In most implementations, customer-configured controls should be described in the system security plan (SSP) with the same rigor applied to any other implemented control, including how the control is configured, who is responsible, and how the implementation satisfies the applicable requirement. Where a control is shared or partly inherited, the SSP generally distinguishes the portion the provider satisfies from the portion your organization configures. Confirm the specific documentation format and expectations against the governing framework and any agency-specific tailoring that applies to your system.

Who is responsible for assessing customer-configured controls during an authorization or assessment?

Because customer-configured controls are implemented by the consuming organization rather than the provider, they generally fall within the scope of the customer's own assessment activities rather than the provider's. Note that assessment and authorization are distinct steps: an assessor evaluates whether controls are implemented effectively, while an authorizing official makes the risk-based decision to authorize operation. Customer-configured controls should be assessed as part of the customer's assessment before the relevant authorizing official acts. Verify scope boundaries against the applicable framework and the responsibility documentation for the specific service.

How do customer-configured controls factor into continuous monitoring after an ATO is granted?

An Authority to Operate (ATO) is time-bound and subject to continuous monitoring, so customer-configured controls do not become static once authorization is granted. Because these controls are configured and maintained by your organization, changes to your configuration, environment, or usage can affect their effectiveness over time. Continuous monitoring programs generally include tracking the ongoing state of customer-responsible controls, not just those maintained by a provider. Confirm the specific monitoring cadence and reporting expectations against your authorization terms and applicable guidance.

How can I identify which controls are customer-configured versus provider-implemented?

The division is typically documented by the provider in a responsibility matrix, sometimes called a customer responsibility matrix or shared responsibility matrix, which allocates each control or control element among the provider, the customer, or a shared arrangement. Because these allocations can vary by service, offering, and revision, you should base your determination on the provider's current documentation rather than general assumptions, and reconcile it against the control baseline applicable to your system. Where allocation language is ambiguous, resolve it with the provider and reflect the agreed responsibility in your system security plan.

Common misconceptions

If a cloud service is FedRAMP authorized, the customer inherits all required controls and has nothing further to configure.

An authorization generally covers only the controls the provider is responsible for. Customer-configured and shared controls remain the customer's responsibility, and a FedRAMP authorization does not automatically satisfy DoD requirements. The customer must still implement, configure, and assess its portion, and confirm applicability against current authoritative sources.

Correctly configuring customer-side controls means the system is both compliant and secure.

Compliance and security are not equivalent. Configuring the controls specified in a responsibility matrix supports compliance objectives, but it does not guarantee the system is secure against all threats. Configuration should be validated, monitored, and maintained over time rather than treated as a one-time checkbox.

Once customer-configured controls are set up and assessed, the resulting authorization is settled.

An Authority to Operate is time-bound and subject to continuous monitoring. Customer-configured controls can drift, be changed, or fall out of compliance, so their status must be reassessed on an ongoing basis rather than assumed to persist from an initial assessment.

Best practices

Obtain and review the provider's Customer Responsibility Matrix in detail, and explicitly identify every control marked as customer-owned or shared before relying on any inherited coverage.

Document the specific configuration settings applied for each customer-configured control, and retain implementation evidence that can support your own assessment and authorization.

Do not assume a provider's authorization satisfies your obligations; verify applicability against the baseline, impact level, and framework that govern your system, and confirm requirements against current official sources.

Treat configuration as ongoing rather than one-time by including customer-configured controls in continuous monitoring to detect and remediate drift before it affects your authorization.

Validate that configured controls actually achieve their intended security objective, distinguishing effective security from mere compliance with a checklist.

Reassess customer-configured controls whenever the environment, provider offering, or applicable revision changes, and align reassessment with the time-bound nature of your Authority to Operate.