How do you assess a cloud or SaaS vendor that will hold BCSI?
A registered entity that wants to place BES Cyber System Information (BCSI) in a cloud or SaaS service must assess that provider before any data moves, because the Responsible Entity owns the CIP-011-3 and CIP-004-7 obligations and cannot hand them to the vendor. Before BCSI goes in, the entity has to assess the provider's access paths, its encryption and key arrangements, its contract terms and its third-party reports, and then record the result. No certificate is issued for this work. Compliance is judged by the Compliance Enforcement Authority, which will ask the entity to show its own evidence. The NERC implementation guidance on cloud solutions for BCSI, dated June 21, 2023, is explicit that the division of security responsibilities with a cloud service provider does not transfer compliance responsibility. The entity, as data owner, must apply the required controls at the third party and be able to demonstrate them.
How deep the assessment goes depends on three things: the provider's architecture, the BCSI categories involved and the evidence the provider can actually produce. A SaaS application that stores documents differs from an IaaS environment where the entity runs its own storage, and both differ from a provider that offers only a general security questionnaire. Start by asking the provider to describe every role that can reach stored data, including support engineers, cloud administrators, eDiscovery operators and any break-glass accounts. The NERC guidance on CIP-011-3 Part 1.2 expects the entity to identify how provider or its own personnel could reach BCSI through those paths. Password protection of storage hardware alone may not be sufficient if the data is not encrypted, so confirm which encryption is applied and who holds the keys (the key arrangements are covered in the sibling topic on encryption and key management).
Then collect the paper evidence that will sit in the entity's compliance file. The guidance names two kinds of administrative evidence: vendor service agreements or vendor service risk assessments that address confidentiality and the provider's access controls, and third-party audit reports such as FedRAMP audit reports or SOC 2 Type 2 reports showing those controls are effective. Read each report for its scope, its period and whether the services and regions in use are covered, and confirm with the provider which exceptions were noted. A report that predates the service configuration the entity will use does not prove that configuration works. Where the contract is silent on incident notification, vendor remote access and disclosure of known vulnerabilities, record that gap and decide whether to negotiate it or to limit what BCSI goes into that service.
What to ask a provider on access, tenancy and encryption
Before BCSI goes into a cloud or SaaS service, the Responsible Entity needs answers on who at the provider can reach the data, how customer data is kept apart from other tenants, and who controls the keys. The cards below set out each question area, what a satisfactory answer looks like and the evidence to request. Confirm every answer with the provider in writing, because provider capabilities differ by service and tier.
Provider personnel access and approvals
Ask which provider roles can read, copy or export customer content, and under what approval. A satisfactory answer names the roles, states that access is granted per request with a recorded business justification, and shows that access expires automatically. Check whether the provider's background screening and training cover staff who can reach BCSI, since CIP-004-7 expects access to BCSI to be authorized and reviewed. Request the provider's access control policy and a sample access log with approvals.
Administrator and break-glass roles
Break-glass accounts are emergency paths that bypass normal controls, so they are where BCSI exposure often hides. Ask how break-glass access is requested, who must approve it, how it is monitored and whether the customer is notified when it is used. NERC guidance asks entities to identify how cloud administrator roles or eDiscovery tools could reach BCSI, so ask the provider to list them. Request the procedure and the most recent break-glass usage record.
Multi-tenant isolation of customer data
Ask how the service keeps one customer's stored data, indexes, backups and temporary files separate from other tenants. Look for logical isolation controls and whether dedicated or single-tenant deployment options exist for the service tier you need. Confirm whether data residency and backup copies stay in the regions you specify. Request the provider's architecture description for tenant separation and the most recent third-party audit report that covers it.
Encryption and who holds keys
Encryption protects BCSI only if the customer controls or can audit the keys. Ask whether data is encrypted at rest and in transit, which algorithms are used, and whether the customer can supply its own keys, hold them in a hardware security module outside the cloud, or revoke them. Confirm who can administer the key service and whether provider staff can use keys without customer approval. The NERC guidance notes that password protection alone may not be sufficient when BCSI is not encrypted, so get the key management design in writing.
Logging and visibility for the customer
Ask what logs the customer can see, how long they are kept and whether they can be exported to the customer's own monitoring system. Useful logs record administrative actions, data access, key use and provider staff sessions with timestamps and identities. Confirm whether the customer can receive alerts for provider access to its data and whether log retention meets the entity's own evidence period. Request a sample log export and the retention statement.
Sub-processor and subcontractor access
Providers often rely on subcontractors for hosting, support or data processing, and each one may create another path to BCSI. Ask for the current list of sub-processors, the locations and roles of each, and how the provider notifies customers of changes. A satisfactory answer includes contractual flow-down of confidentiality and access controls, and a right to object or end the service. Request the sub-processor list and the contract clauses that bind them.
What the contract and vendor risk assessment must cover
The contract and the vendor service risk assessment are the administrative evidence that a CIP auditor will ask for when BCSI sits with a cloud or SaaS provider. The NERC cloud guidance names two items to keep on file: vendor service agreements and vendor service risk assessments that address confidentiality and the provider's access controls. The agreement should state, in terms your compliance lead can point to, who may access BCSI, under what conditions provider personnel may reach it, and how the provider protects it. The risk assessment should record what you tested or reviewed, such as the provider's SOC 2 Type 2 report or FedRAMP audit report, which controls those reports cover, and which gaps you accepted or compensated for. Ask the provider which of its own staff roles, eDiscovery functions, cloud administrator accounts and break-glass procedures could reach your data, and write the answers into the assessment.
CIP-013-2 Part 1.2 sets the procurement topics your supply chain plan must address where they apply to the service. Confirm the contract covers incident notification and coordinated incident response, including who calls whom and within what timeframe. Require notice when provider remote or onsite access to your environment should end, and a process for removing that access. Ask for disclosure of known vulnerabilities in the service, verification of software integrity and authenticity for any code or updates delivered to you, and coordination of vendor remote access controls where the provider connects into systems that support your BCSI. Where a topic does not apply to a SaaS storage service, record why in the assessment so the omission is explained rather than silent.
The contract is evidence you must keep, not only a procurement document. The Responsible Entity remains accountable for CIP-004-7 and CIP-011-3 even when the provider runs the infrastructure, so retain the signed agreement, amendments, the risk assessment and its review dates in your compliance records. Have a lawyer review the confidentiality, audit rights, sub-processor, data location and deletion terms, and have your compliance lead confirm that every CIP obligation you rely on has a matching clause or evidence source. Reassess when the service, the provider's audit report or the CIP requirements change, and confirm with your Regional Entity or counsel how your organization's contract retention and review cycle should be documented.
How FedRAMP and SOC 2 Type 2 reports serve as evidence
A FedRAMP audit report is an assessment package produced by an independent assessor for a cloud service offering that has gone through the U.S. federal authorization process. It documents which security controls were tested for that offering, how they were tested and what the results were. For a NERC CIP entity, it is third-party evidence that the provider's controls were examined. It is administrative evidence that supports your own assessment of the provider under CIP-011-3 and CIP-013-2. It is not a CIP certificate, and no regulator issues one for a cloud service.
- Offering boundary: Confirm that the authorized service, not just the provider's company name, is the one that will hold BCSI. Authorizations often cover specific services or regions.
- Control baseline: Check which control baseline the authorization was granted against and whether the controls relevant to provider personnel access and encryption were tested.
- Authorization status: Confirm the current status of the authorization and any conditions or open items recorded for it.
- Inheritance mapping: Identify which controls the provider handles and which fall to your own configuration and access management.
- Version currency: Ask whether the package you received matches the current service configuration.
Before relying on a FedRAMP package, review its scope, findings and responsibility split with a compliance lead who knows your BCSI handling design.
A SOC 2 Type 2 report is issued by an independent CPA firm under the AICPA attestation framework. It describes the provider's system and the controls it operated over a period, along with the auditor's opinion on whether those controls operated effectively during that period. For a NERC CIP entity, it is third-party evidence that the provider's controls were tested over time, which is more informative than a point-in-time snapshot. It supports your own vendor service risk assessment. It does not certify CIP compliance, and the provider cannot give you one.
- System description: Read whether the described system includes the storage service and the support and administrative functions that could reach BCSI.
- Exceptions: Review each exception noted by the auditor, the provider's response and whether it touches confidentiality or access controls.
- Testing period: Compare the examination window with the period in which you will actually store BCSI.
- Subservice organizations: Identify which sub-providers are carved out and whether their reports are available.
- Trust Services Criteria: Confirm which criteria were in scope, particularly confidentiality, and whether they match your data protection requirements.
Ask your compliance lead to review the exceptions and the complementary user entity controls section before you sign.
Neither report type automatically covers the way your entity uses the service. An authorization or examination can be accurate and still leave a gap for BCSI. Scope and period are the two most common gaps, and the provider's report is only one input into your evidence package. The NERC cloud guidance expects the registered entity, as data owner, to show how the required controls apply at the third party.
- Service mismatch: The reported service may differ from the product tier, region or feature set you buy.
- Period mismatch: A report that ends months before your go-live, or that covers a period before a major provider change, may not reflect current operations.
- Scope exclusions: Some support, logging or backup functions may sit outside the reported boundary.
- Unresolved exceptions: An open exception on access or encryption controls needs a documented decision from you.
- Bridge letters: Ask whether the provider can supply a statement covering the period between the report end date and your review.
Record each gap in your vendor assessment, along with how you addressed it or accepted the residual risk.
Both FedRAMP packages and SOC 2 reports include a description of controls the customer must operate for the provider's controls to be effective. These complementary user entity controls sit with you, not the provider. For BCSI, they often include how you assign and remove cloud accounts, how you protect keys or tenant administrators, how you configure logging and how you verify that access stays within the provisioned list. If you do not operate them, the provider's report does not protect your BCSI.
- Account provisioning: Confirm who in your organization can create, change or remove cloud accounts that reach BCSI.
- Key and admin control: Identify who controls administrative roles and any customer-managed keys.
- Monitoring and review: Assign ownership for reviewing access logs and provider notices.
- Incident coordination: Define how the provider's incident notices reach your CIP-008 process.
- Mapping to evidence: Link each complementary control to the artifact that proves you operate it.
Bring the complementary user entity controls list to your compliance lead and confirm each item has a named owner before BCSI is stored.
How the vendor assessment runs from first request to sign-off
The sequence turns a proposed cloud or SaaS service into a documented go or no-go decision, with each phase producing a record that a CIP auditor can trace back to CIP-011-3 and CIP-004-7. Your own compliance and security teams own every phase, and the provider supplies the material they are asked to produce.
Scope the BCSI and the candidate service
Start by listing exactly which BES Cyber System Information will go into the service, where it sits in the BCSI program, and which provider service model is proposed (SaaS, PaaS or IaaS). Record the data types, the people who need to reach them, and the regions or sub-processors involved. Your compliance lead and the system owner sign this scope note. The step is done when the scope note names the data, the service and the provider's proposed hosting location, so every later question has a fixed target.
Send the provider questionnaire and evidence request
Send a written questionnaire covering how the provider's staff and tools can reach stored data, how tenants are separated, how encryption and keys are managed, and how incidents and vulnerabilities are reported. Attach a request for the provider's current third-party audit reports and the scope of each. Ask the provider for a timeline for its response and confirm that timeline with your own team. The step closes when the provider returns written answers and named evidence, and you log any gaps.
Review provider access paths to BCSI
Map every route by which a person or process could reach BCSI, including provider support staff, cloud administrator roles, eDiscovery or legal hold tools, break-glass accounts, backup operators and sub-processors. For each route, record who holds it, how access is approved and logged, and whether the data is readable in that path. NERC's cloud guidance notes that password protection of storage hardware alone may not be sufficient if BCSI is not encrypted, so this map drives your encryption decision. The step closes with a signed access path register that your team can test.
Assess contract terms and the vendor risk assessment
Compare the provider's service agreement against the confidentiality, access control, notification and disposal terms your CIP-011-3 and CIP-013-2 procurement process requires. Cover incident notification, coordinated incident response, notice when vendor access should end, disclosure of known vulnerabilities, software integrity verification and coordination of remote access controls. Write a vendor service risk assessment that records each residual risk and its owner. The step is done when legal and security sign the contract review and the risk assessment, and any missing terms appear as negotiated changes or documented exceptions.
Review third-party audit reports
Read the FedRAMP audit reports or SOC 2 Type 2 reports the provider supplied, focusing on the scope boundary, the period covered, the controls that test provider access and encryption, and any listed exceptions. Confirm that the services and regions you plan to use fall inside the report scope. Note where a control you depend on is carved out or relies on a complementary control that your organization must run. The step closes with a memo stating which reported controls you accept as administrative evidence and which need compensating controls. Only the independent auditor who issued each report stands behind it.
Test the controls you depend on
Verify the points that matter most to BCSI protection by reviewing configuration exports, key management settings, access logs or a demonstration in a non-production tenant. Confirm that your own team can see who accessed BCSI and that revocation works when staff leave. Where a claim cannot be verified, record it as unverified. The step closes with a test record that lists each check, the evidence reviewed, the tester and the result, which becomes part of your CIP-011-3 evidence file.
Record the go or no-go decision
Bring the scope note, questionnaire responses, access path register, contract review, risk assessment, report memo and test record to a decision meeting led by the CIP Senior Manager or a delegate. The decision states whether BCSI may go into the service, under what conditions, and with which compensating controls and owners. Retain the signed decision and all supporting records under your information retention rules. The step is done when the record is filed and the conditions are assigned to named owners with dates agreed by your team.
Schedule reassessment and change triggers
Set a review cycle for the vendor and define events that reopen the assessment, such as a new sub-processor, a change in hosting region, a new provider support model, a lapsed or changed audit report or a reported incident. Ask the provider to commit to notifying you of these changes in the contract. The step closes with a documented review calendar and trigger list, approved by the same owners who signed the decision. Ask the provider and your own team for the timing of each review rather than assuming a fixed interval.
Where vendor assessments stall or fail an audit
Most failed cloud vendor assessments for BCSI do not fail on a missing document. They fail because the registered entity assumed the provider carried responsibility it cannot transfer, or because the evidence it collected does not reach the storage and access paths an auditor will ask about. Each card below names one such gap and the step that closes it before BCSI moves into the service.
Treating shared responsibility as transferred compliance
A provider's shared responsibility model describes who operates which controls. It does not move the obligation. The NERC cloud BCSI guidance is explicit that the Responsible Entity, as data owner, must apply the required controls, including at third parties, and must be able to demonstrate compliance with CIP-004-7 and CIP-011-3. Before go-live, map each CIP-011-3 and CIP-004-7 control to the party that operates it, and assign an internal owner who keeps the evidence for the parts the provider runs.
Accepting a report that excludes the BCSI service
A FedRAMP audit report or SOC 2 Type 2 report only supports the services inside its stated scope and period. Many providers issue reports covering a parent platform while the storage product holding BCSI sits outside it. Read the system description, confirm the named service and region appear, and check that the testing period covers the months the BCSI will be stored. Where the service is excluded, treat it as a gap and record the compensating control or decision.
Missing break-glass and eDiscovery access paths
Encryption and access lists do not show every route to the data. Provider support engineers, cloud administrators using break-glass accounts, and eDiscovery or legal hold tools can each reach stored content. The NERC guidance asks entities to identify how provider or their own personnel could reach BCSI through these paths. Request a written inventory of privileged and emergency roles, how they are approved, how they are logged, and how the entity is notified when they are used.
Storing unencrypted BCSI without key-holder analysis
Password protection on storage hardware alone may not satisfy CIP-011-3 Part 1.2 when BCSI is not encrypted. Ask whether the service encrypts data at rest by default, who holds the keys in the provider's key management service, and whether the entity can hold or restrict keys outside the provider. Record the answer as a key-holder analysis that names every party able to decrypt the data, because that list determines who can reach BCSI in practice.
Contracts without confidentiality or access terms
A standard online terms-of-service page rarely commits a provider to confidentiality of customer data, notice before access by its staff, or support for audit requests. Procurement under CIP-013-2 Part 1.2 must address incident notification, coordinated incident response, vulnerability disclosure, software integrity, and notice when vendor access should end. Check that the signed agreement contains each applicable topic, with named timelines and the right to receive evidence on request.
No evidence retained at the time of decision
Auditors test whether the entity had a sound basis when it chose the provider, not whether a reassessment was run later. Keep the vendor service risk assessment, the report version reviewed, the scope check, the key-holder analysis, and the approval record together, dated and signed at the time BCSI is first stored. Store them where the audit evidence set for the period can retrieve them, and schedule reassessment when the provider changes its service or reports.
Who owns the assessment, the provider and the auditor
The registered entity owns the outcome. Under the NERC cloud guidance, the division of security responsibilities with a cloud service provider does not transfer compliance responsibility, so the Responsible Entity, as data owner, decides whether BCSI goes into a provider's service and must be able to demonstrate compliance with CIP-004-7 and CIP-011-3 itself. The provider supplies documents, configuration detail, contract terms and third-party reports. It does not take on the entity's controls, and it cannot sign off on them. Keep that split in writing: the entity's internal approval record for the provider, the risk assessment behind it and the business agreement should all name the entity as the accountable party.
An implementation partner such as DeployOpen can help the entity prepare its assessment file. That work includes mapping provider evidence to the CIP-011-3 and CIP-013-2 items the entity must show, setting up customer-side controls such as access roles, key management and logging in the entity's own cloud account, and organizing the file so an auditor can follow it. DeployOpen does not issue reports, attestations or certifications, and it does not stand in for the provider's auditor or the Compliance Enforcement Authority. Confirm this boundary in the statement of work before work starts, so the entity does not mistake a prepared file for an assurance result.
Two parties issue the assurance that counts. The first is the Compliance Enforcement Authority, a Regional Entity or NERC, which monitors the entity's compliance through audits, spot checks and self-certifications. The second is the independent auditor who tests the provider's controls and issues a FedRAMP or SOC 2 Type 2 report, which the entity then reads and relies on as administrative evidence. There is no CIP certificate, so a vendor badge or a consultant's letter does not prove compliance. Ask the provider which report covers the service in scope, its audit period, and whether it lists the controls that matter for BCSI access.
Common questions about assessing cloud vendors for BCSI
Does a SOC 2 Type 2 report alone satisfy CIP-011-3 for cloud-held BCSI?
No. A SOC 2 Type 2 report is one piece of administrative evidence, not a finding that CIP-011-3 is met. NERC's cloud guidance lists third-party audit reports such as SOC 2 Type 2 reports as evidence that a provider's controls operated effectively, but the Responsible Entity still has to show how BCSI is protected, who can reach it, and how that access is limited. The report covers the provider's controls against its chosen criteria, so the entity must check whether the scope includes the service and data types it is buying. Confirm the report's period, exceptions and complementary user entity controls, then map each one to your own CIP-011-3 and CIP-004-7 evidence. The entity owns that mapping, and an independent auditor decides whether the evidence is sufficient.
Can our team assess the cloud provider ourselves?
Often yes, provided your staff can read the provider's contracts, security documentation and third-party reports and test the answers against your own controls. The work covers vendor service agreements, vendor service risk assessments addressing confidentiality and provider access controls, and the provider's personnel access paths such as cloud administrator roles, break-glass accounts and eDiscovery tools. Responsibility does not move to the provider. Whoever runs the assessment, the Responsible Entity remains accountable for demonstrating compliance. An outside implementation partner can prepare the configuration, access records and evidence packages, but it does not issue reports or certify the provider. Ask any partner to state in writing which artifacts it will produce and which parts stay with your team.
How long does a cloud vendor assessment for BCSI take?
The duration depends on the number of services, the BCSI types involved, how many provider documents already exist and how quickly the provider answers questions. No standard duration applies, and this page does not give one. Drivers include whether the provider has a current third-party report covering the relevant service, whether encryption and key ownership are already decided, how many provider personnel access paths must be documented, and whether contract terms need negotiation. Ask any consultant or internal team for a written schedule tied to a defined scope, and confirm which steps depend on the provider's responses. A fixed scope agreed before work starts makes the timeline easier to check.
What does the assessment require from our internal staff?
It requires time from people who own the decisions, not only from the people who run the cloud account. Expect input from CIP compliance owners who define what counts as BCSI, from procurement or legal staff who manage the vendor service agreement, from security staff who review access and key controls, and from the cloud administrators who can show which roles exist and who holds them. Internal staff must also confirm the entity's own access revocation and personnel risk assessment processes under CIP-004-7, since provider personnel access must fit those processes. Ask the provider and any partner to name the internal roles they need, and agree who signs off on each evidence item before work begins.
Can we refuse a cloud provider after the assessment finds gaps?
Yes. Nothing in the NERC cloud guidance requires an entity to accept a provider, and the entity decides whether BCSI may go into a given service. If the assessment shows that provider personnel can reach BCSI in ways you cannot control or document, the options include requiring contract changes, adding customer-held encryption keys, limiting BCSI to a narrower storage scope or keeping the data on premises. Document the decision and the reasons in your CIP-013-2 supply chain risk management process, because procurement must address the listed vendor topics. Confirm with your Regional Entity or counsel how your own program records these decisions.
Can a consultant certify that a cloud provider meets CIP-011-3?
No. There is no CIP certificate, and no consultant can issue one. Compliance is monitored by the Compliance Enforcement Authority, a Regional Entity or NERC, through audits, spot checks, self-certifications and self-reports. A consultant or implementation partner can help you prepare configuration, access documentation and evidence, and can test whether that evidence supports the requirement. Independent auditors and certification bodies issue reports or certificates for frameworks that offer them, such as a FedRAMP or SOC 2 report issued to the provider. Treat any claim of a CIP certificate for a vendor or consultant as a warning sign, and ask the provider which independent reports it holds and their scope.
How DeployOpen prepares the assessment file
DeployOpen prepares the assessment file for cloud and SaaS vendors that will hold BCSI, working inside your own environment and documentation. The organization keeps ownership of its controls and vendor decisions, while DeployOpen organizes the vendor questionnaires, access path analysis, and evidence so your team and your auditor can review it.
How we scope
- Engagements are fixed-scope, with the vendors, services and BCSI types covered agreed in writing before work starts.
- The written scope lists which provider access paths, such as administrator roles and support channels, are reviewed for each vendor.
- Scope also names the documents to be produced, such as the vendor risk assessment and the BCSI inventory, so quotes follow from defined work.
How we build
- We build a structured vendor questionnaire covering provider staff access, encryption ownership, key custody and incident notification terms.
- We map each provider's answers to the CIP-011-3 and CIP-013-2 evidence your team will need to show, flagging gaps for follow-up.
- We review your own configuration of the cloud tenant, including provisioned access and key policies, so the file reflects how the service is actually used.
How we hand over
- You receive a documented assessment file with vendor answers, your evidence index, and the open items that still need provider confirmation.
- Each finding is written so your compliance lead can see which requirement it affects and who on your side owns the follow-up.
- Handover includes a walkthrough with your team so staff can explain the file to internal reviewers or an independent auditor.
How we support
- Ongoing support is available as a retainer for vendor reassessments, contract changes, and new BCSI workloads added to the cloud service.
- Retainers can cover periodic review of provider SOC 2 Type 2 or FedRAMP reports as new versions are issued, with the findings added to your file.
- DeployOpen prepares systems and evidence only. Independent auditors and the Compliance Enforcement Authority make the compliance determination.
Sources and further reading
- NERC RSTC Implementation Guidance: Usage of Cloud Solutions for BES Cyber System Information ↗
- NERC: CIP-011-3, Cyber Security: Information Protection ↗
- NERC: CIP-013-2, Cyber Security: Supply Chain Risk Management ↗
- NERC: CIP-010-4, Cyber Security: Configuration Change Management and Vulnerability Assessments ↗
- NERC: CIP Reliability Standards (status and US effective dates) ↗
