Can BES Cyber System Information be stored in the cloud under NERC CIP?
Yes. BES Cyber System Information (BCSI) can be stored with a cloud service provider under CIP-004-7 and CIP-011-3, which took effect on 1 January 2024, provided the Responsible Entity meets the requirements of those standards for the cloud storage it uses. If your organization is weighing a SaaS, PaaS or IaaS contract for engineering drawings, network diagrams, configuration files or vulnerability reports, the standards do not prohibit it. What they require is that you can identify where the BCSI sits, control who can obtain and use it, and prove both to an auditor. The answer for your environment depends on three things: your BCSI inventory, the access paths the provider and your own staff have to that data, and the evidence you can produce for each.
The organization owns compliance in every case. A cloud provider can run the infrastructure, but under the NERC guidance the Responsible Entity remains the data owner and must apply the required controls, including at third parties. Neither the provider nor DeployOpen can declare the arrangement compliant. The Regional Entity monitors compliance and an independent auditor or Compliance Enforcement Authority judges the evidence during a Compliance Audit or Spot Check. Before the contract is signed, confirm the scope of BCSI that will move, the named roles that will administer the cloud tenancy, and whether the provider's own staff can reach the data through eDiscovery tools, administrator roles or break-glass accounts. The ERO-endorsed NERC implementation guidance *Usage of Cloud Solutions for BES Cyber System Information* (21 June 2023) describes example approaches for meeting CIP-011-3 R1 and CIP-004-7 R6 when BCSI is held in SaaS, PaaS or IaaS services. It is not a checklist and it creates no new requirements. It also does not address running BES Cyber Systems, EACMS or PACS in the cloud, which is a separate question. Read the guidance alongside your own documented approach, because an example in the guidance only helps you if your implementation matches it and your records show that it does. The NERC guidance document is the natural starting point for your compliance and legal teams.
How to identify BCSI in cloud storage
The NERC cloud guidance gives four ways to show where BCSI lives in a provider's environment under CIP-011-3 Part 1.1. Each approach trades off differently on audit evidence, day-to-day effort and how quickly unplanned copies of BCSI are caught, so the choice should follow how your teams actually store and share engineering documents.
A specific site or folder
Designate one storage location, such as a named cloud folder or bucket prefix, and store all BCSI only there. This is the simplest approach to evidence because an auditor can see the location, its access list and its contents in one place. The weakness is drift: a user who saves a diagram to a personal folder or a shared drive outside the designated location falls outside the designation, so you need access logging and periodic searches to detect copies elsewhere. Confirm that the provider's logs can show who wrote to the folder and who read from it.
File-level tagging with metadata
Mark individual files as BCSI using metadata, labels or classification tags, so BCSI can sit alongside non-BCSI content in the same storage. This suits organizations that cannot move existing repositories. Evidence depends on the tags being applied consistently and on the tag itself being protected from edits by ordinary users. Ask how the tooling enforces labels, whether tags survive copying and export, and how you would find untagged BCSI during a review.
Designating an entire application
Treat a whole application, such as an engineering document management system or a vendor-hosted asset repository, as a BCSI repository. Every record inside it is BCSI by default, which removes per-file decisions and makes the access model the single control to explain. The trade-off is scope: the application's administrators, integrations and backups all fall within the protections you describe, so the access and key-holder list tends to be longer. Document which roles can export data and which integrations can read it.
A designated container in the provider's environment
Designate a container inside the provider's platform, such as a dedicated account, project, subscription or encrypted bucket, that holds only BCSI. Isolation at this level makes it easier to show separate access policies and separate key management for BCSI. Evidence should include the container's configuration, its policy definitions and the provider's administrative access paths, since cloud administrator roles and break-glass accounts can reach the container. Confirm that policies on the container are enforced at the provider level and that changes to them are logged.
Catching drift in each approach
Whichever approach you choose, schedule checks that compare where BCSI is found against where the designation says it should be. For folders and containers, run discovery scans and review access and configuration logs. For tagged files, sample untagged documents from the same repositories. For whole applications, review exports and integration logs. Record each check, its result and the remediation, since the checks are the evidence that the designation is still accurate.
Which protections satisfy CIP-011-3 for off-premise BCSI
Electronic technical methods protect the BCSI itself, so that a person who reaches the stored files still cannot read them without the right key or transformation. The NERC cloud guidance lists encryption, data masking, hashing, tokenization and electronic key management as example approaches. The point is to make protection travel with the data rather than depend only on the provider's perimeter.
- Encryption: Encrypt BCSI at rest so that a provider administrator or a break-glass account reading the storage layer does not expose readable content.
- Data masking and tokenization: Replace sensitive values with masked or token substitutes where the operational use does not need the original detail.
- Hashing: Use hashes to verify integrity or to confirm a match without storing readable content, where that fits the use case.
- Electronic key management: Document who can create, rotate, use and revoke the keys, and whether the keys sit with the provider, with you or in an HSM.
- Password protection alone: The NERC guidance warns that password protection of storage hardware may not be sufficient if BCSI is not encrypted, so do not treat a password as the sole electronic control.
Confirm with your auditor which electronic method you rely on for each BCSI repository, and make sure the key custody described in your evidence matches what the provider actually does.
Physical technical methods cover the protections around the facilities and hardware where the provider stores your data. Under CIP-011-3, these are evidence examples such as lock and key or badge management, biometrics and alarms. Most of these controls belong to the provider, so the practical task is to obtain credible proof that they exist and operate, and to decide whether that proof is sufficient for your risk.
- Facility controls: Ask the provider to describe badge or biometric access to data center floors and the alarms that monitor them.
- Visitor and escort rules: Confirm how the provider controls physical entry for maintenance, contractors and visitors.
- Hardware handling: Establish how failed or retired storage media are controlled and sanitized before they leave the provider's custody.
- Evidence of operation: Request recent access review records or third-party audit reports that cover physical controls, rather than relying on a general description.
- Your own facilities: If any BCSI copies remain on premises, apply your own lock, badge and alarm controls to them as well.
Confirm which of these physical controls the provider's own reports cover, and which you must evidence yourself because they fall outside the provider's scope.
Administrative methods are the agreements, assessments and records that show the Responsible Entity has chosen and governed the provider. The NERC cloud guidance gives vendor service risk assessments and business agreements as examples, and it notes that third-party reports such as SOC 2 Type 2 or FedRAMP audit reports can show that the provider's controls operate effectively. These methods do not replace technical protection, but they are often what an auditor asks for first.
- Vendor service risk assessment: Document the risks of storing BCSI with the provider, including provider personnel access and the access paths described in the guidance.
- Business agreements: Include confidentiality terms, provider access controls, notification obligations and deletion commitments in the contract.
- Third-party audit reports: Obtain a SOC 2 Type 2 or FedRAMP report and check its scope, period and any exceptions against the BCSI services you use.
- Ownership of compliance: Remember that the Responsible Entity, as data owner, remains accountable even when the provider shares security responsibilities.
- Periodic review: Reassess the provider and its reports on a schedule your program defines, and record the outcome.
Confirm that your assessment covers the specific service and region where BCSI is stored, not only the provider's general platform.
How provider and internal personnel access BCSI
An assessor will not start with the storage bucket or the database. They will start by asking who can reach the BCSI and by which route. The NERC cloud guidance on CIP-011-3 Part 1.2 expects the Responsible Entity to identify how provider personnel or its own staff could reach BCSI, and it names three paths to check first: eDiscovery tools, cloud administrator roles and break-glass accounts. Before go-live, list each path for every BCSI repository, including the provider's own support and operations roles that sit above your tenant. Confirm with the provider, in writing, which of its staff can reach customer data, under what conditions, and whether that access can be disabled or logged on your side.
Under CIP-004-7 R6, the question is not who holds a login but who can both obtain and use BCSI. Each path above should therefore be treated as provisioned access, meaning the specific grant (a user account with rights, an administrator role assignment, a key or a card) that gives someone the means to reach the data. Your access list should record every grant on each path, the business reason, the authorization, and the individual's personnel risk assessment and training status. Administrator roles and break-glass accounts are the usual gaps: they are often shared, rarely reviewed and granted outside the normal request workflow. Ask whether break-glass credentials are vaulted, whether each use generates an alert, and who approves the reactivation. Where the provider's staff hold access, the entity should be able to show the contractual and risk-assessment basis for that access, not just the provider's own assurance.
Revocation is the control an assessor tests most often on these paths. When someone leaves, changes role or no longer needs a grant, the access must be removed from every path, not only from the primary portal. Build a revocation check that covers directory accounts, cloud IAM roles, eDiscovery case membership, break-glass vault entries and any provider-side ticket for your tenant, then keep dated records showing it was run. Confirm with your provider how quickly it removes its own personnel's access after your request and how it reports that removal back to you. Illustrative example: a former administrator still listed on a break-glass account would leave a live path to BCSI even if the normal login was disabled, and an assessor would expect that gap to be found in your own review before theirs.
How the path to a compliant cloud BCSI store runs
The sequence starts with knowing exactly what BCSI exists and where it would live, then tests the provider and designs controls around that inventory. It ends with an evidence package the registered entity can hand to its own Regional Entity audit team. The organization remains accountable for every step, and the work is only done when each output is documented and reviewable.
Inventory and classify BCSI
The Responsible Entity identifies which documents, drawings, configurations, network diagrams and other materials meet the BCSI definition for its BES Cyber Systems, using its CIP-002 categorization as the scope boundary. Each information set is assigned a classification and an owner, and the team records whether it is already stored anywhere outside its own premises. The step closes with a BCSI register that lists each repository, its contents and its owner. Teams should confirm the register with the people who actually handle the data, since shared drives and vendor portals often hold copies nobody listed.
Assess the provider and its risks
Before any BCSI is uploaded, the entity performs a vendor service risk assessment covering the provider's personnel access paths, multi-tenant isolation, encryption options and incident handling. It reviews the contract for confidentiality terms and access controls, and requests third-party reports such as a SOC 2 Type 2 report or FedRAMP audit documentation where the provider has them. The output is a documented risk decision approved by the entity, with any gaps recorded as conditions or compensating controls. Remember that the NERC cloud guidance places compliance responsibility with the entity, so provider documents support the assessment but do not replace it.
Design identification controls
The entity selects how BCSI will be identified in the cloud under CIP-011-3 Part 1.1, choosing among a designated storage location such as a specific folder or container, file-level tagging with metadata or labels, designating an entire application as a BCSI repository, or a designated container in the provider's environment. The chosen method is written into the information protection program and tied to the register from the first step. The output is a documented identification design that a reviewer can test by picking a file and confirming how it is marked and where it sits.
Design protection and provisioned access
The team sets protection methods for stored BCSI under CIP-011-3 Part 1.2, such as encryption, data masking or tokenization, and documents how provider staff, cloud administrators and break-glass accounts could reach the data, including eDiscovery tools. Under CIP-004-7 R6, access is treated as provisioned when a person can both obtain and use BCSI, so the design maps each user account, role, key and share to a named authorization. The output is an access matrix and a protection specification, reviewed against the vendor risk decision. Password protection of storage hardware alone is not enough when BCSI is unencrypted, so that case must be explicitly resolved.
Collect operating evidence
Once controls are live, the entity gathers evidence that they work as designed. This includes access lists exported from the cloud tenant, authorization records tied to CIP-004-7 training and personnel risk assessments, encryption configuration records, and logs showing access to BCSI locations. Evidence is collected on a recurring schedule the entity sets for itself so gaps surface before an audit. The output is an evidence folder per control, with each item dated, owned and traceable to a requirement part. Teams should confirm which evidence formats their Regional Entity accepts before collection begins.
Hand off to audit preparation
The implementation partner, where one is engaged, delivers the register, risk decision, control designs, access matrix and evidence index to the entity's compliance team. The entity reviews them, resolves open items and decides what it will present to its Regional Entity. The entity, not the implementer, owns the audit response and any mitigation. The handoff is complete when the compliance lead can explain each control, show where its evidence lives, and identify the owner who maintains it. Ask the Regional Entity or your compliance advisor about the audit notification process before scheduling this handoff.
What moving BCSI to the cloud costs and who gets paid
This table compares each cost component of storing BES Cyber System Information in a cloud service, who is paid for it, whether it is one-time or recurring, and what drives it up. Read it as a checklist for building a quote request, because no dollar figures are supplied here and most components depend on your own scope. The main takeaway is that the cloud provider subscription is only one line, and the compliance work around it falls to your organization and its advisers.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Cloud or SaaS subscription | The cloud provider, under its contract | Recurring | Storage volume, service tier, and any add-on for logging or key management. Ask whether the price covers the logging you need for evidence. |
| Internal staff time for BCSI inventory | Your own staff (no external payee) | One-time, then recurring as data changes | Number of repositories, file types, and how many locations hold BCSI. Tagging and designated storage locations reduce the work. |
| Internal staff time for access reviews | Your own staff (no external payee) | Recurring | Number of provisioned users, provider personnel paths, and how often roles change. Tying access to identity groups lowers the effort. |
| Legal and procurement for business agreements | Your legal and procurement teams, and outside counsel if used | One-time at onboarding, with renewals | Negotiating confidentiality terms, breach notice, and audit rights. Standard provider terms may reduce this work. |
| Key management and logging tooling | Tool vendors, or the cloud provider if its native key service is used | Often recurring | Whether keys are provider-held or customer-held, whether an HSM is needed, and how much audit logging is retained. Confirm each license edition. |
| Implementation partner fees | An implementation partner, under a written scope | One-time for setup, optionally recurring for support | The systems in scope, the number of storage locations to configure, and evidence preparation. Ask for deliverables and exclusions in writing. |
| Independent audit fees | The independent auditor or CIP assessor at your audit | Recurring at each audit cycle | Audit scope, sample sizes, and the quality of your evidence. Auditors do not certify compliance; they test your controls and report findings. |
What makes BCSI cloud compliance more or less expensive
Cost and effort for BCSI in the cloud rise or fall with a few decisions: how much BCSI exists and where it sits, who can reach it, how many providers are involved, who holds the encryption keys, and how mature the evidence is. Each driver can be controlled, and each one changes what a CIP auditor will ask to see.
Volume and BCSI repositories
Every location that holds BCSI must be identified, protected and later shown to an auditor. A single designated folder or container is far simpler to scope than BCSI spread across file shares, ticketing tools, engineering drawings and email attachments. Before storing anything, inventory the repositories and limit BCSI to the fewest locations that meet operational needs. Ask any implementation partner to price the inventory and tagging work separately from ongoing monitoring.
Number of people with provisioned access
Under CIP-004-7 R6, access means the ability to both obtain and use BCSI, so provisioned access includes user accounts with rights, physical keys, access cards and encryption keys. Each additional person or service account adds authorization, training records, access reviews and revocation steps. Restrict roles to named functions, avoid shared accounts, and check who holds cloud administrator or break-glass rights, since those paths can reach BCSI even when no one opens it routinely.
Number of cloud providers
Each provider adds a vendor service risk assessment, contract terms on confidentiality and access controls, and a review of its third-party audit reports. The NERC guidance says a cloud provider does not take over compliance responsibility, so the entity must demonstrate controls at every provider. Consolidating BCSI onto one provider that already offers independent audit reports often lowers recurring review effort, but it raises concentration risk that the entity must document.
Customer-held encryption keys
Whether the entity or the provider controls the encryption keys changes who can decrypt BCSI and therefore what must be proven. Customer-managed keys, held outside the cloud or in a hardware security module, add key custody procedures, rotation records and revocation tracking to the program. Provider-managed keys reduce operating work but shift more weight onto contract terms and provider access evidence. Ask for the key holder list and revocation steps as part of any quote.
Evidence maturity
Controls that are documented, automated and repeatable are cheaper to demonstrate than controls that exist only in people's memory. Mature evidence includes tagged repositories, exported access lists, logged provider access, saved risk assessments and dated access reviews. Build these records before an audit notification arrives, because gaps found late usually require reconstruction work. Confirm with the Regional Entity which evidence forms it accepts, since its expectations shape the work.
Scope of the implementation partner
Fixed-scope work agreed in writing makes costs predictable, while open-ended hours make them hard to forecast. Separate one-time items such as repository design, configuration and evidence templates from recurring items such as access reviews, log checks and provider reassessments. Remember that an implementation partner prepares systems and evidence, but only the entity owns its controls and only the Regional Entity or NERC monitors compliance.
Who owns each part of BCSI cloud compliance
The Responsible Entity is the registered entity that owns the BES Cyber System Information (BCSI). NERC's ERO-endorsed guidance on cloud solutions for BCSI states that dividing security tasks with a cloud service provider does not transfer compliance responsibility. The 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.
- BCSI decisions: Deciding which information is BCSI, where it may be stored and which storage locations are designated under CIP-011-3 Part 1.1.
- Protection methods: Choosing and justifying electronic, physical or administrative methods for off-premise BCSI, including whether encryption and key management are in place.
- Provisioned access approvals: Approving who may obtain and use BCSI under CIP-004-7 R6, including provider personnel who could reach it through administrative roles or break-glass accounts.
- Vendor risk and agreements: Owning the vendor service risk assessment and business agreement that address confidentiality and provider access controls.
- Evidence ownership: Keeping the access records, reviews and documentation an auditor will request.
Check that every provider access path you have identified is covered by an approval, a review and a documented method.
An implementation partner such as DeployOpen prepares systems, configurations, access records and evidence packages within a written scope agreed before work starts. The partner does not own the controls, make BCSI classification decisions for the entity, approve access, or issue any audit report or certificate. Those remain with the entity and the independent auditor.
- Configuration preparation: Setting up encryption, key handling, access settings and logging on self-hosted or customer-controlled systems where the scope includes them.
- Access records: Building the provisioned access inventory and the review records that the entity then approves.
- Evidence packages: Assembling documentation that maps each control to its artifacts so the entity can present them to an auditor.
- Gap identification: Reporting where configurations do not match the entity's stated methods, for the entity to decide on.
- Handover: Documenting how the environment runs so the entity's staff can operate and evidence it after the engagement.
Confirm in the statement of work exactly which systems, deliverables and provider accounts are in scope, and who signs off each deliverable.
Compliance is monitored by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms. There is no CIP certificate. Under the NERC Rules of Procedure, Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years, and other registered entities are audited on a risk-based schedule set by the Regional Entity.
- Regional Entity audits: The Regional Entity tests the entity's compliance against the standards and issues the findings that apply to the entity.
- Provider reports as inputs: SOC 2 Type 2 reports or FedRAMP audit reports are produced by the provider's independent assessor. They are administrative evidence showing that provider controls are effective, not an entity certification.
- Scope of testing: The auditor tests what the entity can demonstrate, so gaps in the entity's own records are not covered by provider reports.
- Third-party assessors: Where an entity engages an outside assessor for readiness work, that assessor's view does not replace the Regional Entity's findings.
- Clear separation: Neither DeployOpen nor any other implementation partner issues reports or certificates.
Ask the auditor or Regional Entity which evidence they expect for each BCSI method before the review begins.
Questions buyers ask about BCSI in the cloud
Can a cloud provider hold BES Cyber System Information at all?
Yes. NERC's ERO-endorsed implementation guidance on cloud solutions for BCSI describes example approaches for meeting CIP-011-3 R1 and CIP-004-7 R6 when BCSI sits in SaaS, PaaS or IaaS services. The guidance creates no new requirements and does not cover operating BES Cyber Systems, EACMS or PACS in the cloud. Storage is allowed, but the Responsible Entity remains accountable. The division of security duties with a provider does not move compliance responsibility, so you must still identify your BCSI, protect it, control provisioned access and be able to demonstrate both to an auditor. The NERC cloud guidance is the natural first read.
What does it cost to prepare BCSI for cloud storage?
No public figure for preparation cost is available in the sources used for this page, so ask for a written quote built from scope. The cost has several parts: internal staff time for identifying BCSI and mapping it to CIP-011-3 and CIP-004-7 evidence, provider review and contract work, technical controls such as encryption and key management, access provisioning and reviews, and documentation. Some costs are one-time, such as the initial inventory and design. Others recur, such as access reviews, personnel risk assessments, evidence collection and provider re-assessment. Costs rise with the number of BCSI repositories, the number of people with provisioned access and how many providers are involved.
How long does it take to get BCSI into a cloud service?
The timeline depends on what you have to decide and build, not on a fixed duration. The main drivers are how well your BCSI is already identified, whether the provider's contract and risk assessment need negotiation, how much encryption and key management you must design, how many roles need provisioned access changes, and how much of your CIP-004-7 access program must be extended to the cloud. Your internal change approval and any outside help also set the pace. Ask any implementation partner for a fixed-scope plan with milestones agreed in writing before work starts.
Can our own team handle BCSI cloud storage without outside help?
Often yes, if your team already runs a CIP program and understands CIP-011-3 and CIP-004-7 well enough to map them onto cloud controls. The work involves identifying BCSI by one of the storage approaches in the NERC guidance, protecting it with encryption or other technical methods, documenting who can reach it through provider and administrator paths, and keeping provisioned access evidence current. Outside help is most useful for design review, for building a self-hosted or hybrid control set, or for preparing evidence before an audit. Whatever you choose, the organization keeps ownership of its controls. An implementation partner prepares systems and evidence, and only an independent auditor issues findings.
Is a SaaS provider's SOC 2 Type 2 report enough evidence?
A SOC 2 Type 2 report is useful administrative evidence, but it is not sufficient on its own. NERC's guidance lists third-party reports such as SOC 2 Type 2 or FedRAMP audit reports as examples that show a provider's controls are effective. It still falls to you to show that the report covers the controls relevant to your BCSI, including provider personnel access, encryption and key handling. You must also hold a vendor service agreement or risk assessment that addresses confidentiality and the provider's access controls, and you must map the report's coverage and any exceptions to your own evidence. Check the report period and the scope of the services included.
What must we give an auditor to show BCSI in the cloud is protected?
Expect to show where your BCSI lives, how it is identified, and who can obtain and use it. Auditors commonly look for an inventory of BCSI storage locations, the method used to identify them, encryption or other electronic, physical or administrative protections, a record of provisioned access including user accounts, roles and encryption keys, access review records, and the vendor agreements and risk assessments behind the provider relationship. For provider personnel and break-glass paths, you should document how those accounts could reach BCSI and what controls apply. Confirm the exact evidence list and audit period with your Regional Entity before the engagement.
How to choose a consultant for NERC CIP cloud BCSI
Start by asking what the consultant has actually done with CIP-004-7 and CIP-011-3 in front of an auditor. Ask for named examples of BCSI repositories they have prepared for a Compliance Audit or Spot Check, and ask how they handled the provisioned access evidence under CIP-004-7 R6, which treats a person as having access only when they can both obtain and use the information. A consultant who talks about encryption and says nothing about who can reach the data through eDiscovery tools, cloud administrator roles or break-glass accounts has not worked through the hard part of the NERC cloud guidance. Ask them to walk through the provider access paths for a specific SaaS or IaaS service you already use, and to show where those paths are recorded.
Next, test how the consultant works inside your controls. The organization remains the Responsible Entity and owns the BCSI program, the access decisions and the evidence. A good partner configures the storage locations, access groups, key settings and logging you select, documents them, and leaves you able to run them without outside help. Be wary of any proposal that moves ownership of your controls to the consultant or depends on a tool only they can operate. Insist on a written, fixed scope that lists the systems, storage locations, deliverables and the review points you will sign off, and make sure the proposal states in plain words that the consultant prepares systems and evidence but does not attest, certify or issue audit reports. Only your independent auditor or the Regional Entity's process reaches those conclusions.
For procurement, ask for a sample evidence package before signing. A useful sample includes a BCSI identification record for one storage location, a provisioned access listing with the rights and keys that make access possible, a review record showing how that listing was checked, and the vendor service risk assessment or the provider's SOC 2 Type 2 or FedRAMP report that the consultant relied on. Confirm with the consultant and your own compliance lead how the package maps to your CIP-011-3 and CIP-004-7 requirements, and ask what they would expect an auditor to challenge. The package also shows whether the consultant documents decisions clearly enough for your team to maintain them after the engagement closes.
How DeployOpen prepares BCSI cloud evidence
DeployOpen helps registered entities prepare the systems, access configuration and evidence that support BCSI storage in cloud services under CIP-011-3 and CIP-004-7. The Responsible Entity keeps ownership of its controls and compliance, while DeployOpen plans, implements and documents the technical and administrative records an auditor will ask to see.
How we scope
- Agree in writing which BCSI repositories, cloud services and provider access paths the engagement covers.
- Confirm the identification method for each BCSI location, such as a designated container, tagged files or a dedicated application.
- Record which parts of the cloud estate fall outside scope, including operating BES Cyber Systems, EACMS and PACS.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts.
How we build
- Configure encryption and key management so that key holders and their access paths are visible and recorded.
- Map provisioned access for users, groups and administrative roles, including break-glass and eDiscovery paths.
- Set up logging and access reviews that produce records showing who could obtain and use BCSI.
- Test whether provider or internal administrators could reach unencrypted BCSI through any identified path.
How we hand over
- Deliver a BCSI inventory, data flow records and a description of each protection method used.
- Document the provisioned access model and the procedures for revoking access when personnel change roles or leave.
- Provide an evidence index mapping each artifact to the CIP-011-3 and CIP-004-7 requirement it supports, for your review with your auditor.
How we support
- Support ongoing access reviews, key rotation records and evidence refresh for the period your auditor will sample.
- Revisit the BCSI inventory when new cloud services or repositories are added to the environment.
- Ongoing support, upgrades and continuous testing are available as a retainer agreed in writing.
