Cloud Implementation

Guide for NERC Audits

MICROSOFT CONFIDENTIAL – NDA REQUIRED 1

Cloud Implementation Guide for NERC Audits

Abstract
When electric utilities and other registered entities deploy applications to Microsoft Azure or Azure
Government, they inherit security controls from the underlying cloud platform. Registered Entities are
ultimately responsible for meeting their NERC CIP compliance obligations; however, Microsoft’s existing
independent third-party certifications and attestations such as FedRAMP can be leveraged to help
Registered Entities with their own compliance obligations.

The purpose of this document is to provide technical guidance to assist Registered Entities with NERC
audits for assets deployed to Azure or Azure Government. The attestation vehicle applicable to Azure
and Azure Government is FedRAMP, a comprehensive and rigorous US government assessment and
authorization program. FedRAMP does not replace NERC CIP standards and it does not eliminate the
responsibility that Registered Entities have for NERC CIP compliance obligations. Rather, a Cloud Service
Provider’s existing FedRAMP authorization delivers assurance that NIST-based control evidence mapped
to NERC CIP requirements owned by cloud service provider has already been examined by an accredited
FedRAMP auditor. Registered Entities and NERC CIP auditors are expected to rely on FedRAMP
authorizations rather than conduct their own individual audits of Azure or Azure Government. It would
be infeasible for a Cloud Service Provider to submit to an audit and furnish control evidence each time a
Registered Entity undergoes a NERC audit.

This document provides control mapping between the current set of NERC CIP standards requirements
and NIST SP 800-53 Rev 4 control set that forms the basis for FedRAMP. Moreover, a complete set of
Reliability Standard Audit Worksheets (RSAWs) with Azure control implementation details is provided to
assist Registered Entities.

July 2019

https://aka.ms/AzureNERCGuide

Acknowledgments
Author: Stevan Vidich
Reviewers: Larry Cochrane, Garima Jain, Erin Nord

(c) 2019 Microsoft Corporation. All rights reserved. This document is provided ”as-is”. Information and views expressed in this
document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.

This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy
and use this document for your internal, reference purposes.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 2

Cloud Implementation Guide for NERC Audits

Contents
Introduction .................................................................................................................................................. 4
NERC CIP standards ....................................................................................................................................... 4
FedRAMP....................................................................................................................................................... 6
NERC audit guidance ..................................................................................................................................... 7
Summary ....................................................................................................................................................... 9
Appendix A: Control mapping between NERC CIP requirements and NIST SP 800-53 R4 control set ....... 10
Appendix B: Reliability Standard Audit Worksheets (RSAWs) .................................................................... 45
CIP-002-5.1 – Cyber Security – BES Cyber System Categorization ......................................................... 46
CIP-003-6 – Cyber Security – Security Management Controls................................................................ 50
CIP-004-6 – Cyber Security – Personnel & Training ................................................................................ 58
CIP-005-5 – Cyber Security – Electronic Security Perimeter(s) ............................................................... 87
CIP-006-6 – Cyber Security – Physical Security of BES Cyber Systems ................................................... 99
CIP-007-6 – Cyber Security – System Security Management ............................................................... 116
CIP-008-5 – Cyber Security – Incident Reporting and Response Planning ........................................... 141
CIP-009-6 – Cyber Security – Recovery Plans for BES Cyber Systems................................................... 152
CIP-010-2 – Cyber Security – Configuration Change Management and Vulnerability Assessments .... 165
CIP-011-2 – Cyber Security – Information Protection........................................................................... 180
CIP-014-2 – Physical Security ................................................................................................................ 187

MICROSOFT CONFIDENTIAL – NDA REQUIRED 3

Cloud Implementation Guide for NERC Audits

Introduction
The purpose of this Guide is to assist electric utilities and other Registered Entities subject to NERC CIP
compliance obligations with NERC audits involving assets deployed to the cloud. Prior to reading this
Guide, Registered Entities should review a companion white paper titled “NERC CIP Standards and Cloud
Computing”. The white paper provides an overview of Azure and Azure Government, discusses NERC
CIP compliance considerations for cloud computing, and addresses common security and isolation
concerns pertinent to registered entities considering cloud adoption.

This Cloud Implementation Guide provides detailed technical information for Registered Entity
compliance officers to streamline NERC audits for data and workloads deployed to the cloud. The
existence of this Guide does not diminish the responsibility of Registered Entities for their NERC audits
which are still required to address NERC CIP compliance obligations; instead, the Guide is meant to
furnish Microsoft security control information relevant to NERC CIP requirements by leveraging existing
FedRAMP authorizations for Azure and Azure Government. FedRAMP is a comprehensive and rigorous
assessment and authorization program mandated by the US government and intended for cloud
services. Because the security controls implemented by Microsoft in a given cloud environment are the
same for all cloud tenants, relying on FedRAMP authorization provides a scalable and efficient approach
for addressing audit needs of Registered Entities. It would be infeasible for a Cloud Service Provider to
submit to an audit and furnish control evidence each time a Registered Entity undergoes a NERC audit.
Registered Entities and NERC CIP auditors are expected to rely on existing FedRAMP authorizations
rather than conduct their own individual audits of Azure or Azure Government.

Appendix A provides a control mapping between the current set of NERC CIP standards requirements
and NIST SP 800-53 Rev 4 control set that forms the basis for FedRAMP. This mapping is useful to gain
insight into how NERC CIP standards requirements align with FedRAMP controls and to define the
concept of shared responsibility between Registered Entities and Microsoft. Moreover, a complete set
of Reliability Standard Audit Worksheets (RSAWs) with Azure control implementation details is provided
in Appendix B. Registered Entities are expected to leverage this information as assurance that NERC CIP
requirements for which Microsoft is responsible have been properly assessed and authorized by the
FedRAMP program using the corresponding NIST 800-53 controls.

NERC CIP standards

NERC is a nonprofit regulatory authority whose mission is to ensure the reliability and security of the
North American bulk power system. NERC is subject to oversight by the Federal Energy Regulatory
Commission (FERC) and governmental authorities in Canada. In 2006, FERC granted the Electric
Reliability Organization (ERO) designation to NERC in accordance with the Energy Policy Act of 2005 (U.S.
Public Law 109-58). NERC has jurisdiction over users, owners, and operators of the bulk power system
that serves more than 334 million people.

NERC develops and enforces reliability standards known as NERC CIP standards. In the United States,
FERC approved the first set of CIP standards in 2007 and has continued to do so with every new revision.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 4

Cloud Implementation Guide for NERC Audits

In Canada, the Federal, Provincial, and Territorial Monitoring and Enforcement Sub-group (MESG)
develops provincial summaries for making CIP standards enforceable in Canadian jurisdictions.

As shown in Figure 1, there are currently 11 NERC CIP standards subject to enforcement.

Figure 1: NERC CIP standards subject to enforcement (Source: NERC)

To help Registered Entities assess compliance with NERC CIP standards, NERC has developed Reliability
Standard Audit Worksheets (RSAWs). The RSAWs can assist Registered Entities identify the types of
evidence that would be required as proof of compliance in the course of a NERC audit. However, the
existence of RSAWs does not obviate the need for Registered Entities to examine actual requirements
stated in NERC CIP standards, and entities should always prioritize the language contained in NERC CIP
standards. Moreover, RSAWs contain excerpts from FERC orders and other regulatory references that
should be considered by Entities, but the actual FERC orders take precedence over RSAWs in case of any
discrepancies. Adherence to sample evidence contained in RSAWs does not automatically constitute
compliance with NERC CIP standards.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 5

Cloud Implementation Guide for NERC Audits

FedRAMP
The US Federal Risk and Authorization Management Program (FedRAMP) was established in December
2011 to provide a standardized approach for assessing, monitoring, and authorizing cloud services. It
became operational in June 2012, and it is mandatory for certain US federal procurement programs.

Cloud Service Providers (CSPs) desiring to sell services to a federal agency requiring FedRAMP can take
three paths to demonstrate FedRAMP compliance: 1) earn a Provisional Authorization to Operate (P-
ATO) from the Joint Authorization Board (JAB); 2) receive an Authorization to Operate (ATO) from a
federal agency; or 3) work independently to develop a CSP Supplied Package that meets program
requirements. Each of these paths requires a stringent technical review by the FedRAMP Program
Management Office (PMO) and an assessment by an independent third-party assessor organization
(3PAO) that is accredited by the program.

FedRAMP is based on the National Institute of Standards and Technology (NIST) SP 800-53 Rev 4
standard. Table 1 provides a summary of the NIST SP 800-53 Rev 4 control families. FedRAMP
authorizations are granted at three impact levels based on the NIST FIPS 199 guidelines—Low,
Moderate, and High. Both Azure and Azure Government maintain P-ATOs at the High impact level for
the in-scope services listed at the Trust Center.

Table 1: NIST SP 800-53 Rev 4 control families (Source: NIST)

AC - Access Control PS - Personnel Security

AU - Audit and Accountability PE - Physical and Environmental Protection

AT - Awareness and Training PL - Planning

CM - Configuration Management PM - Program Management

CP - Contingency Planning RA - Risk Assessment

IA - Identification and Authentication CA - Security Assessment and Authorization

IR - Incident Response SC - System and Communications Protection

MA - Maintenance SI - System and Information Integrity

MP - Media Protection SA - System and Services Acquisition

The JAB is the primary governance and decision-making body for FedRAMP. Representatives from the
Department of Defense (DoD), Department of Homeland Security (DHS), and General Services
Administration (GSA) serve on the board. The board grants P-ATO to CSPs that have demonstrated
FedRAMP compliance. It’s important to note that FedRAMP is not a point-in-time certification but an
assessment and authorization program that also comes with provisions for continuous monitoring
mandated by DHS. A CSP is required to furnish a variety of evidence on a monthly basis to demonstrate
continuous compliance, including system inventory reports, vulnerability scans, plan of action and
milestones, etc. FedRAMP is one of the most rigorous and demanding audits that a CSP can undergo.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 6

Cloud Implementation Guide for NERC Audits

NERC audit guidance

A comparison between the FedRAMP Moderate control set and NERC CIP requirements reveals that
the FedRAMP Moderate control baseline encompasses all relevant NERC CIP requirements. Appendix
A provides a control mapping between the current set of NERC CIP standards requirements and NIST SP
800-53 Rev 4 control set that forms the basis for FedRAMP. For assets deployed to the cloud, Appendix
A also provides the control responsibility information indicating who the responsible party is, i.e.,
Registered Entity, Cloud Provider, or Shared. Registered Entities should review this information to
confirm control responsibility for NERC CIP requirements.

Appendix B contains a complete set of Reliability Standard Audit Worksheets (RSAWs) with Azure
control implementation details. This information is based on the current FedRAMP System Security Plan
(SSP) that Registered Entities can download under a non-disclosure agreement from the Service Trust
Portal (see the FedRAMP Reports section). The SSP provides control requirements, as well as the
framework for capturing the system environment, system responsibilities, and the status of baseline
controls required for the system at a given impact level.

Registered Entities are expected to leverage this information as assurance that controls for which CSP is
responsible that are pertinent to NERC CIP requirements are assessed and authorized by the FedRAMP
program. It would be infeasible for a CSP to submit to an audit and furnish control evidence each time a
Registered Entity undergoes a NERC audit. Rather, a CSP’s existing FedRAMP authorization delivers
assurance that NIST-based control evidence mapped to NERC CIP requirements owned by CSP has
already been examined by an accredited FedRAMP auditor. Registered entities and NERC CIP auditors
are expected to rely on FedRAMP authorizations rather than conduct their own individual audits of
Azure or Azure Government.

There are many valid reasons why a Registered Entity subject to NERC CIP compliance obligations might
want to leverage an existing FedRAMP P-ATO or ATO when assessing the security posture of a cloud
services platform:

• Reinventing the established NIST SP 800-53 standard and FedRAMP assessment and
authorization program would be a significant undertaking.
• FedRAMP is already in place, and it is an adopted framework for US Government agencies when
assessing cloud services.
• In the United States, FERC approves NERC CIP standards. As a US federal agency, FERC relies on
FedRAMP when assessing cloud services for their own cloud computing needs. The choice of
FedRAMP as a compliance path for CSPs would be consistent with the approach adopted by
FERC and other US government agencies.
• In Canada, the Federal, Provincial, and Territorial Monitoring and Enforcement Sub-group
develops provincial summaries for making CIP standards enforceable in Canadian jurisdictions.
The Government of Canada has aligned their security control profile for cloud-based services to
the FedRAMP Moderate security control profile to maximize both the interoperability of cloud
services and reusability of the authorization evidence produced by CSPs.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 7

Cloud Implementation Guide for NERC Audits

• FedRAMP relies on an in-depth audit with mandatory provisions for continuous monitoring, and
it provides strong assurances to Registered Entities that audited controls are operating
effectively.
• NERC is interested in enabling Registered Entities to adopt new technologies, including cloud
computing. Given the number of Registered Entities that are subject to NERC CIP compliance
obligations, it would be infeasible for a CSP to accommodate audits initiated by individual
customers. Instead, relying on an existing FedRAMP authorization provides a scalable and
efficient approach for addressing NERC audit requirements for CSPs.

Customers operating Bulk Electric Systems are wholly responsible for ensuring their own compliance
with NERC CIP standards. Neither Azure nor Azure Government constitutes a Bulk Electric System
(BES) or BES Cyber Asset. As stated by NERC, CIP standards apply to the BES. Moreover, according to
the current set of CIP standards and NERC’s Glossary of Terms, BES Cyber Assets perform real-time
functions of monitoring or controlling the BES, and would affect the reliable operation of the BES within
15 minutes of being impaired. To properly accommodate BES Cyber Assets and Protected Cyber Assets
in cloud computing, existing definitions in NERC CIP standards would need to be revised. However,
there are many workloads that deal with CIP sensitive data and do not fall under the 15-minute rule,
including the broad category of BES Cyber System Information (BCSI).

The NERC ERO Enterprise released a Compliance Monitoring and Enforcement Program (CMEP) practice
guide to provide guidance to ERO Enterprise CMEP staff when assessing a Registered Entity’s process
to authorize access to designated BCSI storage locations and any access controls the Registered Entity
implemented. Moreover, NERC reviewed Azure control implementation details and FedRAMP audit
evidence related to NERC CIP-004-6 and CIP-011-2 standards that are applicable to BCSI. Based on the
ERO issued practice guide and reviewed FedRAMP controls to ensure Registered Entities encrypt their
data, no additional guidance or clarification is needed to deploy BCSI and associated workloads in the
cloud; however, Registered Entities are ultimately responsible for compliance with NERC CIP standards
according to their own facts and circumstances. Registered Entities should review the Guide for help
with documenting their processes and evidence used to authorize electronic access to BCSI storage
locations, including encryption key management used for BCSI encryption in Azure and Azure
Government.

Both Azure and Azure Government are suitable for Registered Entities deploying certain workloads
subject to NERC CIP standards, including BCSI workloads. The overarching objective of this Guide is to
provide practical, standardized guidelines to Registered Entities on meeting NERC CIP compliance goals
with CSPs. Registered Entities should be able to document what information is needed from a CSP in
support of a NERC audit and refer to appendices in this Guide for that information. Additional
engagement with a CSP in the course of a NERC audit should not be expected; instead, the mapping of
existing audited FedRAMP controls to the goals set forth by NERC CIP standards provides a complete
picture of CSP’s security posture relevant for NERC audits. However, for questions or clarifications
regarding NERC audits, Registered Entities can request assistance by contacting their Microsoft
representative or opening a ticket with Azure Support.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 8

Cloud Implementation Guide for NERC Audits

Summary
The purpose of this document is to provide technical, how-to guidance to assist Registered Entities with
NERC audits for assets deployed to the cloud. The attestation vehicle applicable to Cloud Service
Providers is FedRAMP, a comprehensive and rigorous US government assessment and authorization
program. FedRAMP does not replace NERC CIP standards and it does not eliminate the responsibility
that Registered Entities have for NERC CIP compliance obligations. Rather, a Cloud Service Provider’s
existing FedRAMP authorization delivers assurance that NIST-based control evidence mapped to NERC
CIP requirements owned by Cloud Service Provider has already been examined by an accredited
FedRAMP auditor. It would be infeasible for a Cloud Service Provider to submit to an audit and furnish
control evidence each time a Registered Entity undergoes a NERC audit. Registered Entities and NERC
CIP auditors would be expected to rely on existing FedRAMP authorizations rather than conduct their
own individual audits of a Cloud Service Provider.

This document provides a control mapping between the current set of NERC CIP standards requirements
and NIST SP 800-53 Rev 4 control set that forms the basis for FedRAMP. Moreover, a complete set of
Reliability Standard Audit Worksheets (RSAWs) with cloud control implementation details is provided to
assist Registered Entities.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 9

Cloud Implementation Guide for NERC Audits

Appendix A: Control mapping between NERC CIP

requirements and NIST SP 800-53 R4 control set

MICROSOFT CONFIDENTIAL – NDA REQUIRED 10

CIP-002-5.1 – Cyber Security – BES Cyber System Categorization
CIP-002-5.1 – Cyber Security – BES Cyber System Categorization
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1 R1. Each Responsible Entity shall implement a process that M1. Acceptable evidence includes, but is not limited to, CM-8 Information Shared
considers each of the following assets for purposes of parts dated electronic or physical lists required by Requirement R1, System Component
1.1 through 1.3: [Violation Risk Factor: High][Time Horizon: and Parts 1.1 and 1.2. Inventory
Operations Planning]

i. Control Centers and backup Control Centers;

ii. Transmission stations and substations;
iii. Generation resources;
iv. Systems and facilities critical to system restoration,
including Blackstart Resources and Cranking Paths and initial
switching requirements;
v. Special Protection Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection Systems specified in
Applicability section 4.2.1 above.

1.1 Identify each of the high impact BES Cyber Systems

according to Attachment 1, Section 1, if any, at each asset;
1.2 Identify each of the medium impact BES Cyber Systems
according to Attachment 1, Section 2, if any, at each asset;
and
1.3 Identify each asset that contains a low impact BES Cyber
System according to Attachment 1, Section 3, if any (a
discrete list of low impact BES Cyber Systems is not required).
2 R2. The Responsible Entity shall: [Violation Risk Factor: M2. Acceptable evidence includes, but is not limited to, CM-8 Information Shared
Lower] [Time Horizon: Operations Planning] electronic or physical dated records to demonstrate that the System Component
Responsible Entity has reviewed and updated, where Inventory
2.1 Review the identifications in Requirement R1 and its parts necessary, the identifications required in Requirement R1
(and update them if there are changes identified) at least and its parts, and has had its CIP Senior Manager or delegate
once every 15 calendar months, even if it has no identified approve the identifications required in Requirement R1 and
items in Requirement R1, and its parts at least once every 15 calendar months, even if it
2.2 Have its CIP Senior Manager or delegate approve the has none identified in Requirement R1 and its parts, as
identifications required by Requirement R1 at least once required by Requirement R2.
every 15 calendar months, even if it has no identified items in
Requirement R1.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 11

Cloud Implementation Guide for NERC Audits

CIP-003-6 – Cyber Security – Security Management Controls

CIP-003-6 – Cyber Security – Security Management Controls
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1 R1. Each Responsible Entity shall review and obtain CIP Senior M1. Examples of evidence may include, but are not limited AC-1 Access Control Shared
Manager approval at least once every 15 calendar months for to, policy documents; revision history, records of review, or AT-1 Security
one or more documented cyber security policies that workflow evidence from a document management system Awareness and
collectively address the following topics: [Violation Risk that indicate review of each cyber security policy at least Training
Factor: Medium] [Time Horizon: Operations Planning] once every 15 calendar months; and documented approval AU-1 Audit and
by the CIP Senior Manager for each cyber security policy. Accountability
1.1 For its high impact and medium impact BES Cyber CA-1 Security
Systems, if any: Assessment and
1.1.1. Personnel and training (CIP-004); Authorization
1.1.2. Electronic Security Perimeters (CIP-005) including CM-1 Configuration
Interactive Remote Access; Management
1.1.3. Physical security of BES Cyber Systems (CIP-006); CP-1 Contingency
1.1.4. System security management (CIP-007); Planning
1.1.5. Incident reporting and response planning (CIP-008); IA-1 Identification
1.1.6. Recovery plans for BES Cyber Systems (CIP-009); and Authentication
1.1.7. Configuration change management and vulnerability IR-1 Incident
assessments (CIP010); Response
1.1.8. Information protection (CIP-011); and MA-1 System
1.1.9. Declaring and responding to CIP Exceptional Maintenance
Circumstances. MP-1 Media
Protection
1.2 For its assets identified in CIP-002 containing low impact PE-1 Physical and
BES Cyber Systems, if any: Environmental
1.2.1. Cyber security awareness; Protection
1.2.2. Physical security controls; PL-1 Security
1.2.3. Electronic access controls for Low Impact External Planning
Routable Connectivity (LERC) and Dial-up Connectivity; and PS-1 Personnel
1.2.4. Cyber Security Incident response Security
RA-1 Risk
Assessment
SA-1 System and
Services Acquisition
SC-1 System and
Communications
Protection

MICROSOFT CONFIDENTIAL – NDA REQUIRED 12

Cloud Implementation Guide for NERC Audits

CIP-003-6 – Cyber Security – Security Management Controls

Part Requirements Measures NIST SP 800-53 R4 Responsibility
SI-1 System and
Information
Integrity
2 R2. Each Responsible Entity with at least one asset identified M2. Evidence shall include each of the documented cyber PL-2 System Shared
in CIP-002 containing low impact BES Cyber Systems shall security plan(s) that collectively include each of the sections Security Plan
implement one or more documented cyber security plan(s) in Attachment 1 and additional evidence to demonstrate AT-1 Security
for its low impact BES Cyber Systems that include the sections implementation of the cyber security plan(s). Additional Awareness and
in Attachment 1. [Violation Risk Factor: Lower] [Time Horizon: examples of evidence per section are located in Attachment Training Policy and
Operations Planning] 2. Procedures
PE-1 Physical and
Note: An inventory, list, or discrete identification of low Environmental
impact BES Cyber Systems or their BES Cyber Assets is not Protection Policy
required. Lists of authorized users are not required. and Procedures
SC-7 Boundary
Protection
IR-1 Incident
Response Policy and
Procedures
3 R3. Each Responsible Entity shall identify a CIP Senior M3. An example of evidence may include, but is not limited CA-6 Security Registered
Manager by name and document any change within 30 to, a dated and approved document from a high-level official Authorization Entity
calendar days of the change. [Violation Risk Factor: Medium] designating the name of the individual identified as the CIP
[Time Horizon: Operations Planning] Senior Manager.
4 R4. The Responsible Entity shall implement a documented M4. An example of evidence may include, but is not limited CA-6 Security Registered
process to delegate authority, unless no delegations are used. to, a dated document, approved by the CIP Senior Manager, Authorization Entity
Where allowed by the CIP Standards, the CIP Senior Manager listing individuals (by name or title) who are delegated the
may delegate authority for specific actions to a delegate or authority to approve or authorize specifically identified
delegates. These delegations shall be documented, including items.
the name or title of the delegate, the specific actions
delegated, and the date of the delegation; approved by the
CIP Senior Manager; and updated within 30 days of any
change to the delegation. Delegation changes do not need to
be reinstated with a change to the delegator. [Violation Risk
Factor: Lower] [Time Horizon: Operations Planning]

MICROSOFT CONFIDENTIAL – NDA REQUIRED 13

Cloud Implementation Guide for NERC Audits

CIP-004-6 – Cyber Security – Personnel & Training

CIP-004-6 Table R1 – Security Awareness Program
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Security awareness that, at least once each calendar quarter, An example of evidence may include, but is not limited to, AT-2 Security Shared
reinforces cyber security practices (which may include documentation that the quarterly reinforcement has been Awareness Training
associated physical security practices) for the Responsible provided. Examples of evidence of reinforcement may
Entity’s personnel who have authorized electronic or include, but are not limited to, dated copies of information
authorized unescorted physical access to BES Cyber Systems. used to reinforce security awareness, as well as evidence of
distribution, such as:
• direct communications (for example, e-mails, memos,
computer-based training); or
• indirect communications (for example, posters, intranet,
or brochures); or
• management support and reinforcement (for example,
presentations or meetings).

CIP-004-6 Table R2 – Cyber Security Training Program

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Training content on: Examples of evidence may include, but are not limited to, AT-2 Security Shared
2.1.1. Cyber security policies; training material such as power point presentations, Awareness Training
2.1.2. Physical access controls; instructor notes, student notes, handouts, or other training CP-3 Contingency
2.1.3. Electronic access controls; materials. Training
2.1.4. The visitor control program; IR-2 Incident
2.1.5. Handling of BES Cyber System Information and its Response Training
storage;
2.1.6. Identification of a Cyber Security Incident and initial
notifications in accordance with the entity’s incident
response plan;
2.1.7. Recovery plans for BES Cyber Systems;
2.1.8. Response to Cyber Security Incidents; and
2.1.9. Cyber security risks associated with a BES Cyber
System’s electronic interconnectivity and interoperability
with other Cyber Assets, including Transient Cyber Assets,
and with Removable Media.
2.2 Require completion of the training specified in Part 2.1 prior Examples of evidence may include, but are not limited to, AT-3 Role-Based Shared
to granting authorized electronic access and authorized training records and documentation of when CIP Exceptional Security Training
unescorted physical access to applicable Cyber Assets, except Circumstances were invoked. AT-4 Security
during CIP Exceptional Circumstances. Training Records
MICROSOFT CONFIDENTIAL – NDA REQUIRED 14
Cloud Implementation Guide for NERC Audits

CIP-004-6 Table R2 – Cyber Security Training Program

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.3 Require completion of the training specified in Part 2.1 at Examples of evidence may include, but are not limited to, AT-2 Security Shared
least once every 15 calendar months. dated individual training records. Awareness Training
AT-3 Role-Based
Security Training
AT-4 Security
Training Records

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 Process to confirm identity. An example of evidence may include, but is not limited to, IA-5 Authenticator Shared
documentation of the Responsible Entity’s process to Management
confirm identity.
3.2 Process to perform a seven-year criminal history records An example of evidence may include, but is not limited to, PS-3 Personnel Shared
check as part of each personnel risk assessment that includes: documentation of the Responsible Entity’s process to Screening
3.2.1 current residence, regardless of duration; and perform a seven-year criminal history records check.
3.2.2 other locations where, during the seven years
immediately prior to the date of the criminal history records
check, the subject has resided for six consecutive months or
more.
If it is not possible to perform a full seven-year criminal
history records check, conduct as much of the seven-year
criminal history records check as possible and document the
reason the full seven-year criminal history records check
could not be performed.
3.3 Criteria or process to evaluate criminal history records checks An example of evidence may include, but is not limited to, PS-3 Personnel Shared
for authorizing access. documentation of the Responsible Entity’s process to Screening
evaluate criminal history records checks.
3.4 Criteria or process for verifying that personnel risk An example of evidence may include, but is not limited to, PS-3 Personnel Shared
assessments performed for contractors or service vendors documentation of the Responsible Entity’s criteria or process Screening
are conducted according to Parts 3.1 through 3.3. for verifying contractors or service vendors personnel risk
assessments.
3.5 Process to ensure that individuals with authorized electronic An example of evidence may include, but is not limited to, PS-3 Personnel Shared
or authorized unescorted physical access have had a documentation of the Responsible Entity’s process for Screening
personnel risk assessment completed according to Parts 3.1 ensuring that individuals with authorized electronic or
to 3.4 within the last seven years. authorized unescorted physical access have had a personnel
risk assessment completed within the last seven years.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 15

Cloud Implementation Guide for NERC Audits

CIP-004-6 Table R4 – Access Management Program

Part Requirements Measures NIST SP 800-53 R4 Responsibility
4.1 Process to authorize based on need, as determined by the An example of evidence may include, but is not limited to, AC-2 Account Shared
Responsible Entity, except for CIP Exceptional Circumstances: dated documentation of the process to authorize electronic Management
4.1.1 Electronic access; access, unescorted physical access in a Physical Security PE-2 Physical Access
4.1.2 Unescorted physical access into a Physical Security Perimeter, and access to designated storage locations, Authorizations
Perimeter; and whether physical or electronic, for BES Cyber System
4.1.3 Access to designated storage locations, whether Information.
physical or electronic, for BES Cyber System Information.
4.2 Verify at least once each calendar quarter that individuals Examples of evidence may include, but are not limited to: AC-2 Account Shared
with active electronic access or unescorted physical access • Dated documentation of the verification between the Management
have authorization records. system generated list of individuals who have been PE-2 Physical Access
authorized for access (i.e., workflow database) and a system Authorizations
generated list of personnel who have access (i.e., user
account listing), or
• Dated documentation of the verification between a list of
individuals who have been authorized for access (i.e.,
authorization forms) and a list of individuals provisioned for
access (i.e., provisioning forms or shared account listing).
4.3 For electronic access, verify at least once every 15 calendar An example of evidence may include, but is not limited to, AC-2 Account Shared
months that all user accounts, user account groups, or user documentation of the review that includes all of the Management
role categories, and their specific, associated privileges are following:
correct and are those that the Responsible Entity determines 1. A dated listing of all accounts/account groups or roles
are necessary. within the system;
2. A summary description of privileges associated with each
group or role;
3. Accounts assigned to the group or role; and
4. Dated evidence showing verification of the privileges for
the group are authorized and appropriate to the work
function performed by people assigned to each account.
4.4 Verify at least once every 15 calendar months that access to An example of evidence may include, but is not limited to, AC-2 Account Shared
the designated storage locations for BES Cyber System the documentation of the review that includes all of the Management
Information, whether physical or electronic, are correct and following: PE-2 Physical Access
are those that the Responsible Entity determines are 1. A dated listing of authorizations for BES Cyber System Authorizations
necessary for performing assigned work functions. information;
2. Any privileges associated with the authorizations; and
3. Dated evidence showing a verification of the
authorizations and any privileges were confirmed correct and
the minimum necessary for performing assigned work
functions.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 16

Cloud Implementation Guide for NERC Audits

CIP-004-6 Table R5 – Access Revocation

Part Requirements Measures NIST SP 800-53 R4 Responsibility
5.1 A process to initiate removal of an individual’s ability for An example of evidence may include, but is not limited to, PS-4 Personnel Shared
unescorted physical access and Interactive Remote Access documentation of all of the following: Termination
upon a termination action, and complete the removals within 1. Dated workflow or sign-off form verifying access removal AC-2 Account
24 hours of the termination action (Removal of the ability for associated with the termination action; and Management
access may be different than deletion, disabling, revocation, 2. Logs or other demonstration showing such persons no AC-2(3) Account
or removal of all access rights). longer have access. Management |
Disable Inactive
Accounts
PE-2 Physical Access
Authorizations
5.2 For reassignments or transfers, revoke the individual’s An example of evidence may include, but is not limited to, AC-2 Account Shared
authorized electronic access to individual accounts and documentation of all of the following: Management
authorized unescorted physical access that the Responsible 1. Dated workflow or sign-off form showing a review of PE-2 Physical Access
Entity determines are not necessary by the end of the next logical and physical access; and Authorizations
calendar day following the date that the Responsible Entity 2. Logs or other demonstration showing such persons no
determines that the individual no longer requires retention of longer have access that the Responsible Entity determines is
that access. not necessary.
5.3 For termination actions, revoke the individual’s access to the An example of evidence may include, but is not limited to, PS-4 Personnel Shared
designated storage locations for BES Cyber System workflow or sign- off form verifying access removal to Termination
Information, whether physical or electronic (unless already designated physical areas or cyber systems containing BES AC-2 Account
revoked according to Requirement R5.1), by the end of the Cyber System Information associated with the terminations Management
next calendar day following the effective date of the and dated within the next calendar day of the termination
termination action. action.
5.4 For termination actions, revoke the individual’s non-shared An example of evidence may include, but is not limited to, AC-2 Account Shared
user accounts (unless already revoked according to Parts 5.1 workflow or sign-off form showing access removal for any Management
or 5.3) within 30 calendar days of the effective date of the individual BES Cyber Assets and software applications as
termination action. determined necessary to completing the revocation of access
and dated within thirty calendar days of the termination
actions.
5.5 For termination actions, change passwords for shared Examples of evidence may include, but are not limited to: AC-2(10) Account Shared
account(s) known to the user within 30 calendar days of the 1. Workflow or sign-off form showing password reset within Management |
termination action. For reassignments or transfers, change 30 calendar days of the termination; Shared / Group
passwords for shared account(s) known to the user within 30 2. Workflow or sign-off form showing password reset within Account Credential
calendar days following the date that the Responsible Entity 30 calendar days of the reassignments or transfers; or Termination
determines that the individual no longer requires retention of 3. Documentation of the extenuating operating circumstance
that access. and workflow or sign-off form showing password reset within

MICROSOFT CONFIDENTIAL – NDA REQUIRED 17

Cloud Implementation Guide for NERC Audits

CIP-004-6 Table R5 – Access Revocation

Part Requirements Measures NIST SP 800-53 R4 Responsibility
If the Responsible Entity determines and documents that 10 calendar days following the end of the operating
extenuating operating circumstances require a longer time circumstance.
period, change the password(s) within 10 calendar days
following the end of the operating circumstances.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 18

Cloud Implementation Guide for NERC Audits

CIP-005-5 – Cyber Security – Electronic Security Perimeter(s)

CIP-005-5 Table R1 – Electronic Security Perimeter
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 All applicable Cyber Assets connected to a network via a An example of evidence may include, but is not limited to, a SC-7 Boundary Registered
routable protocol shall reside within a defined ESP. list of all ESPs with all uniquely identifiable applicable Cyber Protection Entity
Assets connected via a routable protocol within each ESP.
1.2 All External Routable Connectivity must be through an An example of evidence may include, but is not limited to, SC-7 Boundary Registered
identified Electronic Access Point (EAP). network diagrams showing all external routable Protection Entity
communication paths and the identified EAPs.
1.3 Require inbound and outbound access permissions, including An example of evidence may include, but is not limited to, a SC-7(5) Boundary Registered
the reason for granting access, and deny all other access by list of rules (firewall, access control lists, etc.) that Protection | Deny Entity
default. demonstrate that only permitted access is allowed and that by Default / Allow
each access rule has a documented reason. by Exception
1.4 Where technically feasible, perform authentication when An example of evidence may include, but is not limited to, a N/A – Dial-up access Registered
establishing Dial-up Connectivity with applicable Cyber documented process that describes how the Responsible is not provided Entity
Assets. Entity is providing authenticated access through each dial-up through Microsoft
connection. Azure.
1.5 Have one or more methods for detecting known or suspected An example of evidence may include, but is not limited to, SC-7(12) Boundary Registered
malicious communications for both inbound and outbound documentation that malicious communications detection Protection | Host- Entity
communications. methods (e.g. intrusion detection system, application layer Based Protection
firewall, etc.) are implemented. SI-4(4) Information
System Monitoring
| Inbound and
Outbound
Communication
Traffic

CIP-005-5 Table R2 – Interactive Remote Access Management

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Utilize an Intermediate System such that the Cyber Asset Examples of evidence may include, but are not limited to, AC-17 Remote Registered
initiating Interactive Remote Access does not directly access network diagrams or architecture documents. Access Entity
an applicable Cyber Asset.
2.2 For all Interactive Remote Access sessions, utilize encryption An example of evidence may include, but is not limited to, AC-17(2) Remote Registered
that terminates at an Intermediate System. architecture documents detailing where encryption initiates Access | Protection Entity
and terminates. of Confidentiality /
Integrity Using
Encryption

MICROSOFT CONFIDENTIAL – NDA REQUIRED 19

Cloud Implementation Guide for NERC Audits

CIP-005-5 Table R2 – Interactive Remote Access Management

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.3 Require multi-factor authentication for all Interactive Remote An example of evidence may include, but is not limited to, AC-17 Remote Registered
Access sessions. architecture documents detailing the authentication factors Access Entity
used. IA-2 Identification
Examples of authenticators may include, but are not limited and Authentication
to, (Organizational
• Something the individual knows such as passwords or PINs. Users)
This does not include User ID;
• Something the individual has such as tokens, digital
certificates, or smart cards; or
• Something the individual is such as fingerprints, iris scans,
or other biometric characteristics.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 20

Cloud Implementation Guide for NERC Audits

CIP-006-6 – Cyber Security – Physical Security of BES Cyber Systems

CIP-006-6 Table R1 – Physical Security Plan
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Define operational or procedural controls to restrict physical An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
access. documentation that operational or procedural controls exist. Control
1.2 Utilize at least one physical access control to allow An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
unescorted physical access into each applicable Physical language in the physical security plan that describes each Control
Security Perimeter to only those individuals who have Physical Security Perimeter and how unescorted physical
authorized unescorted physical access. access is controlled by one or more different methods and
proof that unescorted physical access is restricted to only
authorized individuals, such as a list of authorized individuals
accompanied by access logs.
1.3 Where technically feasible, utilize two or more different An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
physical access controls (this does not require two completely language in the physical security plan that describes the Control
independent physical access control systems) to collectively Physical Security Perimeters and how unescorted physical
allow unescorted physical access into Physical Security access is controlled by two or more different methods and
Perimeters to only those individuals who have authorized proof that unescorted physical access is restricted to only
unescorted physical access. authorized individuals, such as a list of authorized individuals
accompanied by access logs.
1.4 Monitor for unauthorized access through a physical access An example of evidence may include, but is not limited to, PE-6 Monitoring Cloud Provider
point into a Physical Security Perimeter. documentation of controls that monitor for unauthorized Physical Access
access through a physical access point into a Physical Security
Perimeter.
1.5 Issue an alarm or alert in response to detected unauthorized An example of evidence may include, but is not limited to, PE-6(1) Monitoring Cloud Provider
access through a physical access point into a Physical Security language in the physical security plan that describes the Physical Access |
Perimeter to the personnel identified in the BES Cyber issuance of an alarm or alert in response to unauthorized Intrusion Alarms /
Security Incident response plan within 15 minutes of access through a physical access control into a Physical Surveillance
detection. Security Perimeter and additional evidence that the alarm or Equipment
alert was issued and communicated as identified in the BES
Cyber Security Incident Response Plan, such as manual or
electronic alarm or alert logs, cell phone or pager logs, or
other evidence that documents that the alarm or alert was
generated and communicated.
1.6 Monitor each Physical Access Control System for An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
unauthorized physical access to a Physical Access Control documentation of controls that monitor for unauthorized Control
System. physical access to a PACS. PE-6 Monitoring
Physical Access
1.7 Issue an alarm or alert in response to detected unauthorized An example of evidence may include, but is not limited to, PE-6(1) Monitoring Cloud Provider
physical access to a Physical Access Control System to the language in the physical security plan that describes the Physical Access |
MICROSOFT CONFIDENTIAL – NDA REQUIRED 21
Cloud Implementation Guide for NERC Audits

CIP-006-6 Table R1 – Physical Security Plan

Part Requirements Measures NIST SP 800-53 R4 Responsibility
personnel identified in the BES Cyber Security Incident issuance of an alarm or alert in response to unauthorized Intrusion Alarms /
response plan within 15 minutes of the detection. physical access to Physical Access Control Systems and Surveillance
additional evidence that the alarm or alerts was issued and Equipment
communicated as identified in the BES Cyber Security
Incident Response Plan, such as alarm or alert logs, cell
phone or pager logs, or other evidence that the alarm or
alert was generated and communicated.
1.8 Log (through automated means or by personnel who control An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
entry) entry of each individual with authorized unescorted language in the physical security plan that describes logging Control
physical access into each Physical Security Perimeter, with and recording of physical entry into each Physical Security PE-6 Monitoring
information to identify the individual and date and time of Perimeter and additional evidence to demonstrate that this Physical Access
entry. logging has been implemented, such as logs of physical
access into Physical Security Perimeters that show the
individual and the date and time of entry into Physical
Security Perimeter.
1.9 Retain physical access logs of entry of individuals with An example of evidence may include, but is not limited to, AU-11 Audit Record Cloud Provider
authorized unescorted physical access into each Physical dated documentation such as logs of physical access into Retention
Security Perimeter for at least ninety calendar days. Physical Security Perimeters that show the date and time of PE-3 Physical Access
entry into Physical Security Perimeter. Control
PE-6 Monitoring
Physical Access
1.10 Restrict physical access to cabling and other An example of evidence may include, but is not limited to, PE-9 Power Cloud Provider
nonprogrammable communication components used for records of the Responsible Entity’s implementation of the Equipment and
connection between applicable Cyber Assets within the same physical access restrictions (e.g., cabling and components Cabling
Electronic Security Perimeter in those instances when such secured through conduit or secured cable trays) encryption,
cabling and components are located outside of a Physical monitoring, or equally effective logical protections.
Security Perimeter.
Where physical access restrictions to such cabling and
components are not implemented, the Responsible Entity
shall document and implement one or more of the following:
• encryption of data that transits such cabling and
components; or
• monitoring the status of the communication link composed
of such cabling and components and issuing an alarm or alert
in response to detected communication failures to the
personnel identified in the BES Cyber Security Incident
response plan within 15 minutes of detection; or
• an equally effective logical protection.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 22

Cloud Implementation Guide for NERC Audits

CIP-006-6 Table R2 – Visitor Control Program

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Require continuous escorted access of visitors (individuals An example of evidence may include, but is not limited to, PE-3 Physical Access Cloud Provider
who are provided access but are not authorized for language in a visitor control program that requires Control
unescorted physical access) within each Physical Security continuous escorted access of visitors within Physical
Perimeter, except during CIP Exceptional Circumstances. Security Perimeters and additional evidence to demonstrate
that the process was implemented, such as visitor logs.
2.2 Require manual or automated logging of visitor entry into and An example of evidence may include, but is not limited to, PE-8 Visitor Access Cloud Provider
exit from the Physical Security Perimeter that includes date language in a visitor control program that requires Records
and time of the initial entry and last exit, the visitor’s name, continuous escorted access of visitors within Physical
and the name of an individual point of contact responsible for Security Perimeters and additional evidence to demonstrate
the visitor, except during CIP Exceptional Circumstances. that the process was implemented, such as dated visitor logs
that include the required information.
2.3 Retain visitor logs for at least ninety calendar days. An example of evidence may include, but is not limited to, AU-11 Audit Record Cloud Provider
documentation showing logs have been retained for at least Retention
ninety calendar days. PE-8 Visitor Access
Records

CIP-006-6 Table R3 – Physical Access Control System Maintenance and Testing Program
Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 Maintenance and testing of each Physical Access Control An example of evidence may include, but is not limited to, a PE-3 Physical Access Cloud Provider
System and locally mounted hardware or devices at the maintenance and testing program that provides for testing Control
Physical Security Perimeter at least once every 24 calendar each Physical Access Control System and locally mounted
months to ensure they function properly. hardware or devices associated with each applicable Physical
Security Perimeter at least once every 24 calendar months
and additional evidence to demonstrate that this testing was
done, such as dated maintenance records, or other
documentation showing testing and maintenance has been
performed on each applicable device or system at least once
every 24 calendar months.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 23

Cloud Implementation Guide for NERC Audits

CIP-007-6 – Cyber Security – System Security Management

CIP-007-6 Table R1 – Ports and Services
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Where technically feasible, enable only logical network Examples of evidence may include, but are not limited to: CM-7 Least Shared
accessible ports that have been determined to be needed by • Documentation of the need for all enabled ports on all Functionality
the Responsible Entity, including port ranges or services applicable Cyber Assets and Electronic Access Points, CM-7(1) Least
where needed to handle dynamic ports. If a device has no individually or by group. Functionality |
provision for disabling or restricting logical ports on the • Listings of the listening ports on the Cyber Assets, Periodic Review
device then those ports that are open are deemed needed. individually or by group, from either the device configuration SC-7(5) Boundary
files, command output (such as netstat), or network scans of Protection | Deny
open ports; or by Default / Allow
• Configuration files of host-based firewalls or other device by Exception
level mechanisms that only allow needed ports and deny all
others.
1.2 Protect against the use of unnecessary physical input/output An example of evidence may include, but is not limited to, CM-8(3) Cloud Provider
ports used for network connectivity, console commands, or documentation showing types of protection of physical Information System
Removable Media. input/output ports, either logically through system Component
configuration or physically using a port lock or signage. Inventory |
Automated
Unauthorized
Component
Detection

CIP-007-6 Table R2 – Security Patch Management

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 A patch management process for tracking, evaluating, and An example of evidence may include, but is not limited to, SI-2 Flaw Shared
installing cyber security patches for applicable Cyber Assets. documentation of a patch management process and Remediation
The tracking portion shall include the identification of a documentation or lists of sources that are monitored,
source or sources that the Responsible Entity tracks for the whether on an individual BES Cyber System or Cyber Asset
release of cyber security patches for applicable Cyber Assets basis.
that are updateable and for which a patching source exists.
2.2 At least once every 35 calendar days, evaluate security An example of evidence may include, but is not limited to, an SI-2 Flaw Shared
patches for applicability that have been released since the evaluation conducted by, referenced by, or on behalf of a Remediation
last evaluation from the source or sources identified in Part Responsible Entity of security-related patches released by
2.1. the documented sources at least once every 35 calendar
days.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 24

Cloud Implementation Guide for NERC Audits

CIP-007-6 Table R2 – Security Patch Management

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.3 For applicable patches identified in Part 2.2, within 35 Examples of evidence may include, but are not limited to: SI-2 Flaw Shared
calendar days of the evaluation completion, take one of the • Records of the installation of the patch (e.g., exports from Remediation
following actions: automated patch management tools that provide installation CA-5 Plan of Action
• Apply the applicable patches; or date, verification of BES Cyber System Component software and Milestones
• Create a dated mitigation plan; or revision, or registry exports that show software has been
• Revise an existing mitigation plan. installed); or
Mitigation plans shall include the Responsible Entity’s • A dated plan showing when and how the vulnerability will
planned actions to mitigate the vulnerabilities addressed by be addressed, to include documentation of the actions to be
each security patch and a timeframe to complete these taken by the Responsible Entity to mitigate the vulnerabilities
mitigations. addressed by the security patch and a timeframe for the
completion of these mitigations.
2.4 For each mitigation plan created or revised in Part 2.3, An example of evidence may include, but is not limited to, CA-5 Plan of Action Shared
implement the plan within the timeframe specified in the records of implementation of mitigations. and Milestones
plan, unless a revision to the plan or an extension to the SI-2 Flaw
timeframe specified in Part 2.3 is approved by the CIP Senior Remediation
Manager or delegate.

CIP-007-6 Table R3 – Malicious Code Prevention

Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 Deploy method(s) to deter, detect, or prevent malicious code. An example of evidence may include, but is not limited to, SI-3 Malicious Code Shared
records of the Responsible Entity’s performance of these Protection
processes (e.g., through traditional antivirus, system
hardening, policies, etc.).
3.2 Mitigate the threat of detected malicious code. Examples of evidence may include, but are not limited to: SI-3 Malicious Code Shared
• Records of response processes for malicious code detection Protection
• Records of the performance of these processes when
malicious code is detected.
3.3 For those methods identified in Part 3.1 that use signatures An example of evidence may include, but is not limited to, SI-3 Malicious Code Shared
or patterns, have a process for the update of the signatures documentation showing the process used for the update of Protection
or patterns. The process must address testing and installing signatures or patterns.
the signatures or patterns.

CIP-007-6 Table R4 – Security Event Monitoring

Part Requirements Measures NIST SP 800-53 R4 Responsibility
4.1 Log events at the BES Cyber System level (per BES Cyber Examples of evidence may include, but are not limited to, a SI-4 Information Registered
System capability) or at the Cyber Asset level (per Cyber Asset paper or system generated listing of event types for which System Monitoring Entity

MICROSOFT CONFIDENTIAL – NDA REQUIRED 25

Cloud Implementation Guide for NERC Audits

CIP-007-6 Table R4 – Security Event Monitoring

Part Requirements Measures NIST SP 800-53 R4 Responsibility
capability) for identification of, and after-the-fact the BES Cyber System is capable of detecting and, for
investigations of, Cyber Security Incidents that includes, as a generated events, is configured to log. This listing must
minimum, each of the following types of events: include the required types of events.
4.1.1. Detected successful login attempts;
4.1.2. Detected failed access attempts and failed login
attempts;
4.1.3. Detected malicious code.
4.2 Generate alerts for security events that the Responsible Examples of evidence may include, but are not limited to, SI-4 Information Registered
Entity determines necessitates an alert, that includes, as a paper or system generated listing of security events that the System Monitoring Entity
minimum, each of the following types of events (per Cyber Responsible Entity determined necessitate alerts, including SI-4 (5) Information
Asset or BES Cyber System capability): paper or system generated list showing how alerts are System Monitoring
4.2.1. Detected malicious code from Part 4.1; and configured. | System-Generated
4.2.2. Detected failure of Part 4.1 event logging. Alerts
4.3 Where technically feasible, retain applicable event logs Examples of evidence may include, but are not limited to, AU-4 Audit Storage Registered
identified in Part 4.1 for at least the last 90 consecutive documentation of the event log retention process and paper Capacity Entity
calendar days except under CIP Exceptional Circumstances. or system generated reports showing log retention AU-11 Audit Record
configuration set at 90 days or greater. Retention
4.4 Review a summarization or sampling of logged events as Examples of evidence may include, but are not limited to, AU-6 Audit Review, Registered
determined by the Responsible Entity at intervals no greater documentation describing the review, any findings from the Analysis, and Entity
than 15 calendar days to identify undetected Cyber Security review (if any), and dated documentation showing the Reporting
Incidents. review occurred.

CIP-007-6 Table R5 – System Access Control

Part Requirements Measures NIST SP 800-53 R4 Responsibility
5.1 Have a method(s) to enforce authentication of interactive An example of evidence may include, but is not limited to, IA-2 Identification Shared
user access, where technically feasible. documentation describing how access is authenticated. and Authentication
(Organizational
Users)
5.2 Identify and inventory all known enabled default or other An example of evidence may include, but is not limited to, a IA-5 Authenticator Shared
generic account types, either by system, by groups of listing of accounts by account types showing the enabled or Management
systems, by location, or by system type(s). generic account types in use for the BES Cyber System.
5.3 Identify individuals who have authorized access to shared An example of evidence may include, but is not limited to, AC-2 Account Shared
accounts. listing of shared accounts and the individuals who have Management
authorized access to each shared account.
5.4 Change known default passwords, per Cyber Asset capability. Examples of evidence may include, but are not limited to: IA-5 Authenticator Shared
• Records of a procedure that passwords are changed when Management
new devices are in production; or
MICROSOFT CONFIDENTIAL – NDA REQUIRED 26
Cloud Implementation Guide for NERC Audits

CIP-007-6 Table R5 – System Access Control

Part Requirements Measures NIST SP 800-53 R4 Responsibility
• Documentation in system manuals or other vendor
documents showing default vendor passwords were
generated pseudo-randomly and are thereby unique to the
device.
5.5 For password-only authentication for interactive user access, Examples of evidence may include, but are not limited to: IA-5 (1) Shared
either technically or procedurally enforce the following • System-generated reports or screenshots of the system- Authenticator
password parameters: enforced password parameters, including length and Management |
5.5.1. Password length that is, at least, the lesser of eight complexity; or Password-based
characters or the maximum length supported by the Cyber • Attestations that include a reference to the documented Authentication
Asset; and procedures that were followed.
5.5.2. Minimum password complexity that is the lesser of
three or more different types of characters (e.g., uppercase
alphabetic, lowercase alphabetic, numeric, nonalphanumeric)
or the maximum complexity supported by the Cyber Asset.
5.6 Where technically feasible, for password-only authentication Examples of evidence may include, but are not limited to: IA-5 Authenticator Shared
for interactive user access, either technically or procedurally • System-generated reports or screenshots of the system- Management
enforce password changes or an obligation to change the enforced periodicity of changing passwords; or
password at least once every 15 calendar months. • Attestations that include a reference to the documented
procedures that were followed.
5.7 Where technically feasible, either: Examples of evidence may include, but are not limited to: AC-7 Unsuccessful Shared
• Limit the number of unsuccessful authentication attempts; • Documentation of the account lockout parameters; or Logon Attempts
or • Rules in the alerting configuration showing how the system
• Generate alerts after a threshold of unsuccessful notified individuals after a determined number of
authentication attempts. unsuccessful login attempts.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 27

Cloud Implementation Guide for NERC Audits

CIP-008-5 – Cyber Security – Incident Reporting and Response Planning

CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 One or more processes to identify, classify, and respond to An example of evidence may include, but is not limited to, IR-4 Incident Shared
Cyber Security Incidents. dated documentation of Cyber Security Incident response Handling
plan(s) that include the process to identify, classify, and IR-8 Incident
respond to Cyber Security Incidents. Response Plan
1.2 One or more processes to determine if an identified Cyber Examples of evidence may include, but are not limited to, IR-6 Incident Shared
Security Incident is a Reportable Cyber Security Incident and dated documentation of Cyber Security Incident response Reporting
notify the Electricity Sector Information Sharing and Analysis plan(s) that provide guidance or thresholds for determining
Center (ES-ISAC), unless prohibited by law. Initial notification which Cyber Security Incidents are also Reportable Cyber
to the ES-ISAC, which may be only a preliminary notice, shall Security Incidents and documentation of initial notices to the
not exceed one hour from the determination of a Reportable Electricity Sector Information Sharing and Analysis Center
Cyber Security Incident. (ES-ISAC).
1.3 The roles and responsibilities of Cyber Security Incident An example of evidence may include, but is not limited to, IR-8 Incident Shared
response groups or individuals. dated Cyber Security Incident response process(es) or Response Plan
procedure(s) that define roles and responsibilities (e.g.,
monitoring, reporting, initiating, documenting, etc.) of Cyber
Security Incident response groups or individuals.
1.4 Incident handling procedures for Cyber Security Incidents. An example of evidence may include, but is not limited to, IR-4 Incident Shared
dated Cyber Security Incident response process(es) or Handling
procedure(s) that address incident handling (e.g.,
containment, eradication, recovery/incident resolution).

CIP-008-5 Table R2 – Cyber Security Incident Response Plan Implementation and Testing
Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Test each Cyber Security Incident response plan(s) at least Examples of evidence may include, but are not limited to, IR-3 Incident Shared
once every 15 calendar months: dated evidence of a lessons-learned report that includes a Response Testing
• By responding to an actual Reportable Cyber Security summary of the test or a compilation of notes, logs, and
Incident; communication resulting from the test. Types of exercises
• With a paper drill or tabletop exercise of a Reportable may include discussion or operations based exercises.
Cyber Security Incident; or
• With an operational exercise of a Reportable Cyber Security
Incident.
2.2 Use the Cyber Security Incident response plan(s) under Examples of evidence may include, but are not limited to, IR-3 Incident Shared
Requirement R1 when responding to a Reportable Cyber incident reports, logs, and notes that were kept during the Response Testing
Security Incident or performing an exercise of a Reportable incident response process, and follow-up documentation

MICROSOFT CONFIDENTIAL – NDA REQUIRED 28

Cloud Implementation Guide for NERC Audits

CIP-008-5 Table R2 – Cyber Security Incident Response Plan Implementation and Testing
Part Requirements Measures NIST SP 800-53 R4 Responsibility
Cyber Security Incident. Document deviations from the that describes deviations taken from the plan during the
plan(s) taken during the response to the incident or exercise. incident or exercise.
2.3 Retain records related to Reportable Cyber Security Incidents. An example of evidence may include, but is not limited to, IR-8 Incident Shared
dated documentation, such as security logs, police reports, Response Plan
emails, response forms or checklists, forensic analysis results,
restoration records, and post-incident review notes related
to Reportable Cyber Security Incidents.

CIP-008-5 Table R3 – Cyber Security Incident Response Plan Review, Update, and Communication
Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 No later than 90 calendar days after completion of a Cyber An example of evidence may include, but is not limited to, all IR-8 Incident Shared
Security Incident response plan(s) test or actual Reportable of the following: Response Plan
Cyber Security Incident response: 1. Dated documentation of post incident(s) review
3.2.1. Document any lessons learned or document the meeting notes or follow-up report showing lessons
absence of any lessons learned; learned associated with the Cyber Security Incident
3.2.2. Update the Cyber Security Incident response plan response plan(s) test or actual Reportable Cyber
based on any documented lessons learned associated with Security Incident response or dated documentation
the plan; and stating there were no lessons learned;
3.2.3. Notify each person or group with a defined role in 2. Dated and revised Cyber Security Incident response
the Cyber Security Incident response plan of the updates to plan showing any changes based on the lessons
the Cyber Security Incident response plan based on any learned; and
documented lessons learned. 3. Evidence of plan update distribution including, but not
limited to:
• Emails;
• USPS or other mail service;
• Electronic distribution system; or
• Training sign-in sheets.
3.2 No later than 60 calendar days after a change to the roles or An example of evidence may include, but is not limited to: IR-8 Incident Shared
responsibilities, Cyber Security Incident response groups or 1. Dated and revised Cyber Security Incident response Response Plan
individuals, or technology that the Responsible Entity plan with changes to the roles or responsibilities,
determines would impact the ability to execute the plan: responders or technology; and
3.2.1. Update the Cyber Security Incident response plan(s); 2. Evidence of plan update distribution including, but not
and limited to:
3.2.2. Notify each person or group with a defined role in • Emails;
the Cyber Security Incident response plan of the updates. • USPS or other mail service;
• Electronic distribution system; or
• Training sign-in sheets.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 29
Cloud Implementation Guide for NERC Audits

CIP-009-6 – Cyber Security – Recovery Plans for BES Cyber Systems

CIP-009-6 Table R1 – Recovery Plan Specifications
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Conditions for activation of the recovery plan(s). An example of evidence may include, but is not limited to, CP-2 Contingency Shared
one or more plans that include language identifying Plan
conditions for activation of the recovery plan(s).
1.2 Roles and responsibilities of responders. An example of evidence may include, but is not limited to, CP-2 Contingency Shared
one or more recovery plans that include language identifying Plan
the roles and responsibilities of responders.
1.3 One or more processes for the backup and storage of An example of evidence may include, but is not limited to, CP-9 Information Shared
information required to recover BES Cyber System documentation of specific processes for the backup and System Backup
functionality. storage of information required to recover BES Cyber System
functionality.
1.4 One or more processes to verify the successful completion of An example of evidence may include, but is not limited to, CP-9(1) Information Shared
the backup processes in Part 1.3 and to address any backup logs, workflow or other documentation confirming that the System Backup |
failures. backup process completed successfully and backup failures, if Testing for
any, were addressed. Reliability / Integrity
1.5 One or more processes to preserve data, per Cyber Asset An example of evidence may include, but is not limited to, AU-9 Protection of Shared
capability, for determining the cause of a Cyber Security procedures to preserve data, such as preserving a corrupted Audit Information
Incident that triggers activation of the recovery plan(s). Data drive or making a data mirror of the system before CP-9 Information
preservation should not impede or restrict recovery. proceeding with recovery. System Backup

CIP-009-6 Table R2 – Recovery Plan Implementation and Testing

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Test each of the recovery plans referenced in Requirement R1 An example of evidence may include, but is not limited to, CP-4 Contingency Shared
at least once every 15 calendar months: dated evidence of a test (by recovering from an actual Plan Testing
• By recovering from an actual incident; incident, with a paper drill or tabletop exercise, or with an
• With a paper drill or tabletop exercise; or operational exercise) of the recovery plan at least once every
• With an operational exercise. 15 calendar months. For the paper drill or full operational
exercise, evidence may include meeting notices, minutes, or
other records of exercise findings.
2.2 Test a representative sample of information used to recover An example of evidence may include, but is not limited to, CP-4 Contingency Registered
BES Cyber System functionality at least once every 15 operational logs or test results with criteria for testing the Plan Testing Entity
calendar months to ensure that the information is useable usability (e.g. sample tape load, browsing tape contents) and
and is compatible with current configurations. compatibility with current system configurations (e.g. manual
or automated comparison checkpoints between backup
media contents and current configuration).

MICROSOFT CONFIDENTIAL – NDA REQUIRED 30

Cloud Implementation Guide for NERC Audits

CIP-009-6 Table R2 – Recovery Plan Implementation and Testing

Part Requirements Measures NIST SP 800-53 R4 Responsibility
An actual recovery that incorporates the information used to
recover BES Cyber System functionality substitutes for this
test.
2.3 Test each of the recovery plans referenced in Requirement R1 Examples of evidence may include, but are not limited to, CP-4 Contingency Shared
at least once every 36 calendar months through an dated documentation of: Plan Testing
operational exercise of the recovery plans in an environment • An operational exercise at least once every 36 calendar
representative of the production environment. months between exercises, that demonstrates recovery in a
representative environment; or
An actual recovery response may substitute for an • An actual recovery response that occurred within the 36
operational exercise. calendar month timeframe that exercised the recovery plans.

CIP-009-6 Table R3 – Recovery Plan Review, Update, and Communications

Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 No later than 90 calendar days after completion of a recovery An example of evidence may include, but is not limited to, all CP-4 Contingency Shared
plan test or actual recovery: of the following: Plan Testing
3.1.1. Document any lessons learned associated with a 1. Dated documentation of identified deficiencies or
recovery plan test or actual recovery or document the lessons learned for each recovery plan test or actual
absence of any lessons learned; incident recovery or dated documentation stating
3.1.2. Update the recovery plan based on any documented there were no lessons learned;
lessons learned associated with the plan; and 2. Dated and revised recovery plan showing any
3.1.3. Notify each person or group with a defined role in changes based on the lessons learned; and
the recovery plan of the updates to the recovery plan based 3. Evidence of plan update distribution including, but
on any documented lessons learned. not limited to:
• Emails;
• USPS or other mail service;
• Electronic distribution system; or
• Training sign-in sheets.
3.2 No later than 60 calendar days after a change to the roles or An example of evidence may include, but is not limited to, all CP-4 Contingency Shared
responsibilities, responders, or technology that the of the following: Plan Testing
Responsible Entity determines would impact the ability to 1. Dated and revised recovery plan with changes to the
execute the recovery plan: roles or responsibilities, responders, or technology;
3.2.1. Update the recovery plan; and and
3.2.2. Notify each person or group with a defined role in 2. Evidence of plan update distribution including, but
the recovery plan of the updates. not limited to:
• Emails;
• USPS or other mail service;

MICROSOFT CONFIDENTIAL – NDA REQUIRED 31

Cloud Implementation Guide for NERC Audits

CIP-009-6 Table R3 – Recovery Plan Review, Update, and Communications

Part Requirements Measures NIST SP 800-53 R4 Responsibility
• Electronic distribution system; or
• Training sign-in sheets.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 32

Cloud Implementation Guide for NERC Audits

CIP-010-2 – Cyber Security – Configuration Change Management and Vulnerability Assessments

CIP-010-2 Table R1 – Configuration Change Management
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Develop a baseline configuration, individually or by group, Examples of evidence may include, but are not limited to: CM-2 Baseline Shared
which shall include the following items: • A spreadsheet identifying the required items of the Configuration
1.1.1 Operating system(s) (including version) or firmware baseline configuration for each Cyber Asset, individually or
where no independent operating system exists; by group; or
1.1.2 Any commercially available or open-source • A record in an asset management system that identifies the
application software (including version) intentionally required items of the baseline configuration for each Cyber
installed; Asset, individually or by group.
1.1.3 Any custom software installed;
1.1.4 Any logical network accessible ports; and
1.1.5 Any security patches applied.
1.2 Authorize and document changes that deviate from the Examples of evidence may include, but are not limited to: CM-2 Baseline Shared
existing baseline configuration. • A change request record and associated electronic Configuration
authorization (performed by the individual or group with the CM-3 Configuration
authority to authorize the change) in a change management Change Control
system for each change; or
• Documentation that the change was performed in
accordance with the requirement.
1.3 For a change that deviates from the existing baseline An example of evidence may include, but is not limited to, CM-2(1) Baseline Shared
configuration, update the baseline configuration as necessary updated baseline documentation with a date that is within Configuration |
within 30 calendar days of completing the change. 30 calendar days of the date of the completion of the Reviews and
change. Updates
1.4 For a change that deviates from the existing baseline An example of evidence may include, but is not limited to, a CM-4 Security Shared
configuration: list of cyber security controls verified or tested along with the Impact Analysis
1.4.1 Prior to the change, determine required cyber dated test results.
security controls in CIP-005 and CIP-007 that could be
impacted by the change;
1.4.2 Following the change, verify that required cyber
security controls determined in 1.4.1 are not adversely
affected; and
1.4.3 Document the results of the verification.
1.5 Where technically feasible, for each change that deviates An example of evidence may include, but is not limited to, a CM-2 Baseline Shared
from the existing baseline configuration: list of cyber security controls tested along with successful Configuration
1.5.1 Prior to implementing any change in the production test results and a list of differences between the production
environment, test the changes in a test environment or test and test environments with descriptions of how any
the changes in a production environment where the test is differences were accounted for, including of the date of the
performed in a manner that minimizes adverse effects, that test.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 33
Cloud Implementation Guide for NERC Audits

CIP-010-2 Table R1 – Configuration Change Management

Part Requirements Measures NIST SP 800-53 R4 Responsibility
models the baseline configuration to ensure that required
cyber security controls in CIP-005 and CIP-007 are not
adversely affected; and
1.5.2 Document the results of the testing and, if a test
environment was used, the differences between the test
environment and the production environment, including a
description of the measures used to account for any
differences in operation between the test and production
environments.

CIP-010-2 Table R2 – Configuration Monitoring

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Monitor at least once every 35 calendar days for changes to An example of evidence may include, but is not limited to, CM-2(1) Baseline Shared
the baseline configuration (as described in Requirement R1, logs from a system that is monitoring the configuration along Configuration |
Part 1.1). Document and investigate detected unauthorized with records of investigation for any unauthorized changes Reviews and
changes. that were detected. Updates
CM-3 Configuration
Change Control
CM-5 Access
Restrictions for
Change

CIP-010-2 Table R3 – Vulnerability Assessments

Part Requirements Measures NIST SP 800-53 R4 Responsibility
3.1 At least once every 15 calendar months, conduct a paper or Examples of evidence may include, but are not limited to: CA-7 Continuous Shared
active vulnerability assessment. • A document listing the date of the assessment (performed Monitoring
at least once every 15 calendar months), the controls CA-8 Penetration
assessed for each BES Cyber System along with the method Testing
of assessment; or RA-5 Vulnerability
• A document listing the date of the assessment and the Scanning
output of any tools used to perform the assessment.
3.2 Where technically feasible, at least once every 36 calendar An example of evidence may include, but is not limited to, a CA-7 Continuous Shared
months: document listing the date of the assessment (performed at Monitoring
3.2.1 Perform an active vulnerability assessment in a test least once every 36 calendar months), the output of the tools CA-8 Penetration
environment, or perform an active vulnerability assessment used to perform the assessment, and a list of differences Testing
in a production environment where the test is performed in a between the production and test environments with

MICROSOFT CONFIDENTIAL – NDA REQUIRED 34

Cloud Implementation Guide for NERC Audits

CIP-010-2 Table R3 – Vulnerability Assessments

Part Requirements Measures NIST SP 800-53 R4 Responsibility
manner that minimizes adverse effects, that models the descriptions of how any differences were accounted for in RA-5 Vulnerability
baseline configuration of the BES Cyber System in a conducting the assessment. Scanning
production environment; and
3.2.2 Document the results of the testing and, if a test
environment was used, the differences between the test
environment and the production environment, including a
description of the measures used to account for any
differences in operation between the test and production
environments.
3.3 Prior to adding a new applicable Cyber Asset to a production An example of evidence may include, but is not limited to, a CM-4 Security Shared
environment, perform an active vulnerability assessment of document listing the date of the assessment (performed Impact Analysis
the new Cyber Asset, except for CIP Exceptional prior to the commissioning of the new Cyber Asset) and the
Circumstances and like replacements of the same type of output of any tools used to perform the assessment.
Cyber Asset with a baseline configuration that models an
existing baseline configuration of the previous or other
existing Cyber Asset.
3.4 Document the results of the assessments conducted An example of evidence may include, but is not limited to, a CA-5 Plan of Action Shared
according to Parts 3.1, 3.2, and 3.3 and the action plan to document listing the results or the review or assessment, a and Milestones
remediate or mitigate vulnerabilities identified in the list of action items, documented proposed dates of
assessments including the planned date of completing the completion for the action plan, and records of the status of
action plan and the execution status of any remediation or the action items (such as minutes of a status meeting,
mitigation action items. updates in a work order system, or a spreadsheet tracking
the action items).

CIP-010-2 R4 – Configuration Change Management and Vulnerability Assessments

Part Requirements Measures NIST SP 800-53 R4 Responsibility
4 R4. Each Responsible Entity, for its high impact and medium M4. Evidence shall include each of the documented plan(s) AC-19 Access Registered
impact BES Cyber Systems and associated Protected Cyber for Transient Cyber Assets and Removable Media that Control for Mobile Entity
Assets, shall implement, except under CIP Exceptional collectively include each of the applicable sections in Devices
Circumstances, one or more documented plan(s) for Attachment 1 and additional evidence to demonstrate MP-4 Media
Transient Cyber Assets and Removable Media that include implementation of plan(s) for Transient Cyber Assets and Storage
the sections in Attachment 1. [Violation Risk Factor: Medium] Removable Media. Additional examples of evidence per MP-7 Media Use
[Time Horizon: Long-term Planning and Operations Planning] section are located in Attachment 2. If a Responsible Entity
does not use Transient Cyber Asset(s) or Removable Media,
examples of evidence include, but are not limited to, a
statement, policy, or other document that states the

MICROSOFT CONFIDENTIAL – NDA REQUIRED 35

Cloud Implementation Guide for NERC Audits

CIP-010-2 R4 – Configuration Change Management and Vulnerability Assessments

Part Requirements Measures NIST SP 800-53 R4 Responsibility
Responsible Entity does not use Transient Cyber Asset(s) or
Removable Media.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 36

Cloud Implementation Guide for NERC Audits

CIP-011-2 – Cyber Security – Information Protection

CIP-011-2 Table R1 – Information Protection
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1.1 Method(s) to identify information that meets the definition of Examples of acceptable evidence include, but are not limited MP-1 Media Registered
BES Cyber System Information. to: Protection Policy Entity
• Documented method to identify BES Cyber System and Procedures
Information from entity’s information protection program; or
• Indications on information (e.g., labels or classification)
that identify BES Cyber System Information as designated in
the entity’s information protection program; or
• Training materials that provide personnel with sufficient
knowledge to recognize BES Cyber System Information; or
• Repository or electronic and physical location designated
for housing BES Cyber System Information in the entity’s
information protection program.
1.2 Procedure(s) for protecting and securely handling BES Cyber Examples of acceptable evidence include, but are not limited SC-28 Protection of Shared
System Information, including storage, transit, and use. to: Information at Rest
• Procedures for protecting and securely handling, which MP-4 Media
include topics such as storage, security during transit, and Storage
use of BES Cyber System Information; or MP-5 Media
• Records indicating that BES Cyber System Information is Transport
handled in a manner consistent with the entity’s MP-7 Media Use
documented procedure(s).

CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal

Part Requirements Measures NIST SP 800-53 R4 Responsibility
2.1 Prior to the release for reuse of applicable Cyber Assets that Examples of acceptable evidence include, but are not limited MP-6 Media Shared
contain BES Cyber System Information (except for reuse to: Sanitization
within other systems identified in the “Applicable Systems” • Records tracking sanitization actions taken to prevent
column), the Responsible Entity shall take action to prevent unauthorized retrieval of BES Cyber System Information such
the unauthorized retrieval of BES Cyber System Information as clearing, purging, or destroying; or
from the Cyber Asset data storage media. • Records tracking actions such as encrypting, retaining in
the Physical Security Perimeter or other methods used to
prevent unauthorized retrieval of BES Cyber System
Information.
2.2 Prior to the disposal of applicable Cyber Assets that contain Examples of acceptable evidence include, but are not limited MP-6 Media Cloud Provider
BES Cyber System Information, the Responsible Entity shall to: Sanitization
take action to prevent the unauthorized retrieval of BES
MICROSOFT CONFIDENTIAL – NDA REQUIRED 37
Cloud Implementation Guide for NERC Audits

CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal

Part Requirements Measures NIST SP 800-53 R4 Responsibility
Cyber System Information from the Cyber Asset or destroy • Records that indicate that data storage media was
the data storage media. destroyed prior to the disposal of an applicable Cyber Asset;
or
• Records of actions taken to prevent unauthorized retrieval
of BES Cyber System Information prior to the disposal of an
applicable Cyber Asset.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 38

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

CIP-014-2 – Physical Security
Part Requirements Measures NIST SP 800-53 R4 Responsibility
1 Each Transmission Owner shall perform an initial risk Examples of acceptable evidence may include, but are not N/A Registered
assessment and subsequent risk assessments of its limited to, dated written or electronic documentation of the Entity
Transmission stations and Transmission substations (existing risk assessment of its Transmission stations and Transmission
and planned to be in service within 24 months) that meet the substations (existing and planned to be in service within 24
criteria specified in Applicability Section 4.1.1. The initial and months) that meet the criteria in Applicability Section 4.1.1
subsequent risk assessments shall consist of a transmission as specified in Requirement R1. Additionally, examples of
analysis or transmission analyses designed to identify the acceptable evidence may include, but are not limited to,
Transmission station(s) and Transmission substation(s) that if dated written or electronic documentation of the
rendered inoperable or damaged could result in instability, identification of the primary control center that operationally
uncontrolled separation, or Cascading within an controls each Transmission station or Transmission
Interconnection. substation identified in the Requirement R1 risk assessment
as specified in Requirement R1, Part 1.2.
1.1. Subsequent risk assessments shall be performed:
• At least once every 30 calendar months for a
Transmission Owner that has identified in its
previous risk assessment (as verified according to
Requirement R2) one or more Transmission stations
or Transmission substations that if rendered
inoperable or damaged could result in instability,
uncontrolled separation, or Cascading within an
Interconnection; or
• At least once every 60 calendar months for a
Transmission Owner that has not identified in its
previous risk assessment (as verified according to
Requirement R2) any Transmission stations or
Transmission substations that if rendered inoperable
or damaged could result in instability, uncontrolled
separation, or Cascading within an Interconnection.

1.2. The Transmission Owner shall identify the primary

control center that operationally controls each Transmission
station or Transmission substation identified in the
Requirement R1 risk assessment.
2 Each Transmission Owner shall have an unaffiliated third Examples of acceptable evidence may include, but are not N/A Registered
party verify the risk assessment performed under limited to, dated written or electronic documentation that Entity
Requirement R1. The verification may occur concurrent with the Transmission Owner completed an unaffiliated third
MICROSOFT CONFIDENTIAL – NDA REQUIRED 39
Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

Part Requirements Measures NIST SP 800-53 R4 Responsibility
or after the risk assessment performed under Requirement verification of the Requirement R1 risk assessment and
R1. satisfied all of the applicable provisions of Requirement R2,
including, if applicable, documenting the technical basis for
2.1. Each Transmission Owner shall select an unaffiliated not modifying the Requirement R1 identification as specified
verifying entity that is either: under Part 2.3. Additionally, examples of evidence may
• A registered Planning Coordinator, Transmission include, but are not limited to, written or electronic
Planner, or Reliability Coordinator; or documentation of procedures to protect information under
• An entity that has transmission planning or analysis Part 2.4.
experience.

2.2. The unaffiliated third-party verification shall verify the

Transmission Owner’s risk assessment performed under
Requirement R1, which may include recommendations for
the addition or deletion of a Transmission station(s) or
Transmission substation(s). The Transmission Owner shall
ensure the verification is completed within 90 calendar days
following the completion of the Requirement R1 risk
assessment.

2.3. If the unaffiliated verifying entity recommends that the

Transmission Owner add a Transmission station(s) or
Transmission substation(s) to, or remove a Transmission
station(s) or Transmission substation(s) from, its
identification under Requirement R1, the Transmission
Owner shall either, within 60 calendar days of completion of
the verification, for each recommended addition or removal
of a Transmission station or Transmission substation:
• Modify its identification under Requirement R1
consistent with the recommendation; or
• Document the technical basis for not modifying the
identification in accordance with the
recommendation.

2.4. Each Transmission Owner shall implement procedures,

such as the use of non-disclosure agreements, for protecting
sensitive or confidential information made available to the
unaffiliated third-party verifier and to protect or exempt

MICROSOFT CONFIDENTIAL – NDA REQUIRED 40

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

Part Requirements Measures NIST SP 800-53 R4 Responsibility
sensitive or confidential information developed pursuant to
this Reliability Standard from public disclosure.
3 For a primary control center(s) identified by the Transmission Examples of acceptable evidence may include, but are not N/A Registered
Owner according to Requirement R1, Part 1.2 that a) limited to, dated written or electronic notifications or Entity
operationally controls an identified Transmission station or communications that the Transmission Owner notified each
Transmission substation verified according to Requirement Transmission Operator, as applicable, according to
R2, and b) is not under the operational control of the Requirement R3.
Transmission Owner: the Transmission Owner shall, within
seven calendar days following completion of Requirement R2,
notify the Transmission Operator that has operational control
of the primary control center of such identification and the
date of completion of Requirement R2.

3.1. If a Transmission station or Transmission substation

previously identified under Requirement R1 and verified
according to Requirement R2 is removed from the
identification during a subsequent risk assessment performed
according to Requirement R1 or a verification according to
Requirement R2, then the Transmission Owner shall, within
seven calendar days following the verification or the
subsequent risk assessment, notify the Transmission
Operator that has operational control of the primary control
center of the removal.
4 Each Transmission Owner that identified a Transmission Examples of evidence may include, but are not limited to, AU-6 Audit Review, Cloud Provider
station, Transmission substation, or a primary control center dated written or electronic documentation that the Analysis, and (for primary
in Requirement R1 and verified according to Requirement R2, Transmission Owner or Transmission Operator conducted an Reporting control center)
and each Transmission Operator notified by a Transmission evaluation of the potential threats and vulnerabilities of a
Owner according to Requirement R3, shall conduct an physical attack to their respective Transmission station(s),
evaluation of the potential threats and vulnerabilities of a Transmission substation(s) and primary control center(s) as
physical attack to each of their respective Transmission specified in Requirement R4.
station(s), Transmission substation(s), and primary control
center(s) identified in Requirement R1 and verified according
to Requirement R2. The evaluation shall consider the
following:

4.1. Unique characteristics of the identified and verified

Transmission station(s), Transmission substation(s), and
primary control center(s);

MICROSOFT CONFIDENTIAL – NDA REQUIRED 41

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

Part Requirements Measures NIST SP 800-53 R4 Responsibility
4.2. Prior history of attack on similar facilities taking into
account the frequency, geographic proximity, and severity of
past physical security related events; and
4.3. Intelligence or threat warnings received from sources
such as law enforcement, the Electric Reliability Organization
(ERO), the Electricity Sector Information Sharing and Analysis
Center (ES-ISAC), U.S. federal and/or Canadian governmental
agencies, or their successors.
5 Each Transmission Owner that identified a Transmission Examples of evidence may include, but are not limited to, PE-1 Physical and Cloud Provider
station, Transmission substation, or primary control center in dated written or electronic documentation of its physical Environmental (for primary
Requirement R1 and verified according to Requirement R2, security plan(s) that covers their respective identified and Protection Policy control center)
and each Transmission Operator notified by a Transmission verified Transmission station(s), Transmission substation(s), and Procedures
Owner according to Requirement R3, shall develop and and primary control center(s) as specified in Requirement R5,
implement a documented physical security plan(s) that and additional evidence demonstrating execution of the
covers their respective Transmission station(s), Transmission physical security plan according to the timeline specified in
substation(s), and primary control center(s). The physical the physical security plan.
security plan(s) shall be developed within 120 calendar days
following the completion of Requirement R2 and executed
according to the timeline specified in the physical security
plan(s). The physical security plan(s) shall include the
following attributes:

5.1. Resiliency or security measures designed collectively to

deter, detect, delay, assess, communicate, and respond to
potential physical threats and vulnerabilities identified during
the evaluation conducted in Requirement R4.
5.2. Law enforcement contact and coordination information.
5.3. A timeline for executing the physical security
enhancements and modifications specified in the physical
security plan.
5.4. Provisions to evaluate evolving physical threats, and their
corresponding security measures, to the Transmission
station(s), Transmission substation(s), or primary control
center(s).
6 Each Transmission Owner that identified a Transmission Examples of evidence may include, but are not limited to, N/A Registered
station, Transmission substation, or primary control center written or electronic documentation that the Transmission Entity
identified in Requirement R1 and verified according to Owner or Transmission Operator had an unaffiliated third
Requirement R2, and each Transmission Operator notified by party review the evaluation performed under Requirement

MICROSOFT CONFIDENTIAL – NDA REQUIRED 42

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

Part Requirements Measures NIST SP 800-53 R4 Responsibility
a Transmission Owner according to Requirement R3, shall R4 and the security plan(s) developed under Requirement R5
have an unaffiliated third party review the evaluation as specified in Requirement R6 including, if applicable,
performed under Requirement R4 and the security plan(s) documenting the reasons for not modifying the evaluation or
developed under Requirement R5. The review may occur security plan(s) in accordance with a recommendation under
concurrently with or after completion of the evaluation Part 6.3. Additionally, examples of evidence may include, but
performed under Requirement R4 and the security plan are not limited to, written or electronic documentation of
development under Requirement R5. procedures to protect information under Part 6.4

6.1. Each Transmission Owner and Transmission Operator

shall select an unaffiliated third-party reviewer from the
following:
• An entity or organization with electric industry
physical security experience and whose review staff
has at least one member who holds either a Certified
Protection Professional (CPP) or Physical Security
Professional (PSP) certification.
• An entity or organization approved by the ERO.
• A governmental agency with physical security
expertise.
• An entity or organization with demonstrated law
enforcement, government, or military physical
security expertise.
6.2. The Transmission Owner or Transmission Operator,
respectively, shall ensure that the unaffiliated third-party
review is completed within 90 calendar days of completing
the security plan(s) developed in Requirement R5. The
unaffiliated third-party review may, but is not required to,
include recommended changes to the evaluation performed
under Requirement R4 or the security plan(s) developed
under Requirement R5.
6.3. If the unaffiliated third-party reviewer recommends
changes to the evaluation performed under Requirement R4
or security plan(s) developed under Requirement R5, the
Transmission Owner or Transmission Operator shall, within
60 calendar days of the completion of the unaffiliated third-
party review, for each recommendation:
• Modify its evaluation or security plan(s) consistent
with the recommendation; or

MICROSOFT CONFIDENTIAL – NDA REQUIRED 43

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

Part Requirements Measures NIST SP 800-53 R4 Responsibility
• Document the reason for not modifying the
evaluation or security plan(s) consistent with the
recommendation.
6.4. Each Transmission Owner and Transmission Operator
shall implement procedures, such as the use of non-
disclosure agreements, for protecting sensitive or confidential
information made available to the unaffiliated third-party
reviewer and to protect or exempt sensitive or confidential
information developed pursuant to this Reliability Standard
from public disclosure.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 44

Appendix B: Reliability Standard Audit Worksheets (RSAWs)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 45

Cloud Implementation Guide for NERC Audits

CIP-002-5.1 – Cyber Security – BES Cyber System Categorization

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement a process that considers each of the following assets for purposes of
parts 1.1 through 1.3: [Violation Risk Factor: High][Time Horizon: Operations Planning]
i. Control Centers and backup Control Centers;
ii. Transmission stations and substations;
iii. Generation resources;
iv. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths
and initial switching requirements;
v. Special Protection Systems that support the reliable operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above*.
1.1. Identify each of the high impact BES Cyber Systems according to Attachment 1, Section 1, if any, at each
asset;
1.2. Identify each of the medium impact BES Cyber Systems according to Attachment 1, Section 2, if any, at
each asset; and
1.3. Identify each asset that contains a low impact BES Cyber System according to Attachment 1, Section 3, if
any (a discrete list of low impact BES Cyber Systems is not required).
M1. Acceptable evidence includes, but is not limited to, dated electronic or physical lists required by Requirement
R1, and Parts 1.1 and 1.2.

* See the full text of CIP-002-5.1 for this reference.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity (RE) is responsible for developing and documenting an inventory of customer-deployed resources that
supports tracking and reporting and includes any information the customer has deemed necessary to achieve effective
accountability. For example, REs can use Azure Resource Manager (ARM) to see all resource providers and registration
status for their subscription. ARM scripts are available to export inventory information to Excel spreadsheet for
subsequent processing and presentation to NERC auditors. When querying information for a particular resource provider,
location data is limited to region names, e.g., East US, East US 2, etc. Inventory information does not correlate Azure
resources provisioned by a RE to underlying physical assets residing in Microsoft datacenter. Customers are not permitted
to access physical infrastructure directly, e.g., customers can provision Virtual Machines or interact with virtual disks, as
opposed to access physical servers or write directly to raw storage. In the current set of NERC CIP standards, there is
heavy emphasis on physical assets within the Electronic Security Perimeter (e.g., the very specific term “in those devices”
when referring to BES Cyber Assets), and no provisions for key cloud concepts such as virtualization, logical isolation, and
multi-tenancy. To properly accommodate BES Cyber Assets and Protected Cyber Assets in cloud computing, existing
definitions in NERC CIP standards would need to be revised or augmented.

In a multi-tenant cloud such as Azure or Azure Government, the underlying physical infrastructure resources are shared
by multiple tenants. For examples, Virtual Machines (VMs) belonging to multiple tenants can run on the same physical
server. Moreover, hyper-scale cloud platforms are designed to anticipate and recover from failure at any given time. This
means that VMs or storage accounts belonging to a RE can be migrated from unhealthy to healthy nodes at any given
time. This process is fully automated and completely transparent to Registered Entities. Tenant separation is achieved

MICROSOFT CONFIDENTIAL – NDA REQUIRED 46

Cloud Implementation Guide for NERC Audits

via logical isolation across compute, storage, and networking resources. Registered Entity is responsible for maintaining
an inventory of assets under customer control, e.g., customer Virtual Machines within Azure and physical assets outside
Azure. Microsoft does not inspect or approve applications that customers deploy in Azure. Consequently, Microsoft does
not know how BES Cyber Systems are designed, deployed, and operated, or even what resources comprise a BES Cyber
System. Neither Azure nor Azure Government constitutes a BES Cyber System or BES Cyber Asset.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-8 Information System Component Inventory: Azure collects inventory information for physical devices,
native OS, guest OS, web endpoints, network, database, and other systems. After collecting inventory information, Azure
performs month-over-month data analysis and reconciliation. Any changes to, additions to, or removals from the
inventory are identified, verified, and explained. Azure collects, at minimum, the following information for each asset in
the inventory: 1) Unique asset identifier, and 2) OS name.

Azure Infrastructure maintains an inventory of information system components. The inventory is documented and
maintained in an inventory database system, which keeps the inventory accurate and up to date through new installations
and decommissioning of devices. Inventory information is provided to the FedRAMP Joint Authorization Board (JAB) to
meet Microsoft’s FedRAMP Continuous Monitoring obligations.

Section 4.01 of Microsoft Security Program Policy (MSPP) states:

“All Assets used to support the delivery of Microsoft's services must be accounted for and have an identified owner. The
Asset Owner is accountable for maintaining a complete inventory of their information assets; establishing acceptable and
authorized use of the assets; and providing the appropriate level of protection for the assets throughout their life cycle.
The inventory must clearly identify, at a minimum, each asset's owner, current location, and classification. The
classification must be based on standards set by the applicable security group."

For all asset types, the inventory is consistent with the FedRAMP authorization boundary because it is kept up to date with
new installations and decommissioning of devices. The inventory for all Azure Infrastructure assets includes the following
details where applicable:

• IP address
• Name
• Property Group
• Serial Number
• ID
• Datacenter
• Collocation
• Location
• Rack
• Slot Number
• Environment
• Manufacturer
• Model
• OS Version
• OS Service Pack Version
• Item Type

However, inventory information maintained by Microsoft is not correlated to BES Cyber Systems as Microsoft has no
knowledge how a BES Cyber System is designed and operated or even which virtual resources provisioned by a Registered
Entity constitute a BES Cyber System.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 47

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure - FedRAMP Microsoft Azure 3.05 7/31/2018 303-304 Covers NIST 800-53 CM-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Supporting Evidence and Documentation

R2. The Responsible Entity shall: [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]
2.1 Review the identifications in Requirement R1 and its parts (and update them if there are changes
identified) at least once every 15 calendar months, even if it has no identified items in Requirement R1,
and
2.2 Have its CIP Senior Manager or delegate approve the identifications required by Requirement R1 at least
once every 15 calendar months, even if it has no identified items in Requirement R1.
M2. Acceptable evidence includes, but is not limited to, electronic or physical dated records to demonstrate that the
Responsible Entity has reviewed and updated, where necessary, the identifications required in Requirement R1
and its parts, and has had its CIP Senior Manager or delegate approve the identifications required in
Requirement R1 and its parts at least once every 15 calendar months, even if it has none identified in
Requirement R1 and its parts, as required by Requirement R2.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is accountable for keeping the inventory of its information assets up to date, as well as tracking and
documenting any changes to the inventory. Registered Entity is responsible for updating the inventory of assets under
customer control, e.g., customer Virtual Machines within Azure and physical assets outside Azure at least once every 15
months.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-8 Information System Component Inventory: After collecting inventory information, Azure performs
month-over-month data analysis and reconciliation. Any changes to, additions to, or removals from the inventory are
identified, verified, and explained. Azure updates the system inventory at least monthly and includes updated inventory
information in the monthly Continuous Monitoring report provided to the FedRAMP Joint Authorization Board (JAB).

MICROSOFT CONFIDENTIAL – NDA REQUIRED 48

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 303-304 Covers NIST 800-53 CM-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 49

Cloud Implementation Guide for NERC Audits

CIP-003-6 – Cyber Security – Security Management Controls

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall review and obtain CIP Senior Manager approval at least once every 15 calendar
months for one or more documented cyber security policies that collectively address the following topics:
[Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
1.1 For its high impact and medium impact BES Cyber Systems, if any:
1.1.1. Personnel & training (CIP-004);
1.1.2. Electronic Security Perimeters (CIP-005) including Interactive Remote Access;
1.1.3. Physical security of BES Cyber Systems (CIP-006);
1.1.4. System security management (CIP-007);
1.1.5. Incident reporting and response planning (CIP-008);
1.1.6. Recovery plans for BES Cyber Systems (CIP-009);
1.1.7. Configuration change management and vulnerability assessments (CIP-010);
1.1.8. Information protection (CIP-011); and
1.1.9. Declaring and responding to CIP Exceptional Circumstances.
1.2 For its assets identified in CIP-002 containing low impact BES Cyber Systems, if any:
1.2.1. Cyber security awareness;
1.2.2. Physical security controls;
1.2.3. Electronic access controls for Low Impact External Routable Connectivity (LERC) and Dial-up
Connectivity; and
1.2.4. Cyber Security Incident response
M1. Examples of evidence may include, but are not limited to, policy documents; revision history, records of review,
or workflow evidence from a document management system that indicate review of each cyber security policy
at least once every 15 calendar months; and documented approval by the CIP Senior Manager for each cyber
security policy.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for policies applicable to assets under customer control, e.g., customer Virtual Machines
within Azure and physical assets outside Azure.

Cloud Provider Responsibility: Yes

Microsoft Cloud Security Policy applies to all information and processes used in the conduct of Microsoft business. All
Microsoft employees, interns, vendors, contingent staff, partners, and business guests are accountable and responsible
for complying with this policy within their designated roles. This includes those located at facilities not owned by
Microsoft. This corporate policy is maintained and reviewed annually, aligned with supporting corporate policies and
functions. Customers can download the Microsoft Cloud Security Policy from the Service Trust Portal (see FAQ and White
Papers section).
MICROSOFT CONFIDENTIAL – NDA REQUIRED 50
Cloud Implementation Guide for NERC Audits

Moreover, Azure maintains a set of Standard Operating Procedures (SOPs) that are reviewed by the FedRAMP auditor
(3PAO) in the course of a FedRAMP audit. These SOPs cover Azure policies corresponding to CIP-003-6 R1 requirements,
as documented in the table below. There is no counterpart to 1.1.9 Declaring and responding to CIP Exceptional
Circumstances because Registered Entity is expected to be solely responsible for such policy.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Microsoft Cloud Microsoft Security N/A 2/1/2018 1-11 Covers personnel
Security Policy.pdf Policy Program screening, security training,
(External) physical and environmental
security, system security,
incident management,
business continuity
management, change
management, security
vulnerability and
penetration testing, access
control, etc.
Education and Cloud and Enterprise 2018.01 2/28/2018 1-10 Personnel and Training
Awareness 2018.01 Security Education & (CIP-004)
(C+E Security).docx Awareness SOP
Network Security Microsoft Azure 2018.01 10/24/2018 1-21 Electronic Security
(AZURE) 2018.01.docx Network Security SOP Perimeter (CIP-005) and
Remote Access
Microsoft intranet Secure Access NA 11/5/2018 NA Remote access to
content Workstation (SAW) production systems
use and operation
policy
Datacenter Physical Standard Operating 13.4 6/28/2018 1-185 Physical Security of BES
Security SOP for Procedures for Cyber Systems (CIP-006)
Operations v13.4.docx Operations
Network Security Microsoft Azure 2018.01 10/24/2018 1-21 System Security
(AZURE) 2018.01.docx Network Security SOP Management (CIP-007)
Vulnerability Risk C+AI Security SOP: 5.2 10/29/2018 1-31 System Security
Management SOP 5.2 Vulnerability Risk Management (CIP-007)
(C+AI Security).docx Management
Anti-Malware (AZURE) Anti-Malware SOP 2018.01 3/12/2018 1-12 System Security
2018.01.docx Management (CIP-007)
Logging and Logging and 2017.01 12/29/2017 1-27 System Security
Monitoring (AZURE) Monitoring SOP Management (CIP-007)
2017.01.docx
Access Control Access Control SOP 2018.03 8/14/2018 1-32 System Security
(AZURE) 2018.03.docx Management (CIP-007)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 51

Cloud Implementation Guide for NERC Audits

Incident Management Incident 2018.01 8/23/2018 1-42 Incident Reporting and

SOP 2018.01.docx Management SOP Response Planning (CIP-
008)
Business Continuity Business Continuity 2018.02 11/5/2018 1-27 Recovery Plans for BES
and Disaster Recovery and Disaster Recover Cyber Systems (CIP-009)
(AZURE) 2018.02.docx SOP
Microsoft Cloud – Microsoft Business NA 11/13/2018 1-13 Recovery Plans for BES
Enterprise Business Continuity Cyber Systems (CIP-009)
Continuity Management
Management (EBCM) Program
Program.pdf
Security Baseline C+E Security Baseline 2017.01 2/2/2018 1-15 Configuration Change
Governance SOP (C+E Program SOP Management and
Security) 2017.01.docx Vulnerability Assessments
(CIP-010)
Software Change and Software Change and 2018.01 9/17/2018 1-43 Configuration Change
Release Management Release Management Management and
(AZURE) 2018.01.docx Azure SOP Vulnerability Assessments
(CIP-010)
Hardware Change and Hardware Change 2017.01 12/8/2017 1-22 Configuration Change
Release Management and Release Management and
(AZURE) 2017.01.docx Management SOP Vulnerability Assessments
(CIP-010)
Vulnerability Risk C+AI Security SOP: 5.2 10/29/2018 1-31 Configuration Change
Management SOP 5.2 Vulnerability Risk Management and
(C+AI Security).docx Management Vulnerability Assessments
(CIP-010)
Penetration Testing Penetration Testing 2018.01 2/9/2018 1-8 Configuration Change
(AZURE) 2018.01.docx SOP Management and
Vulnerability Assessments
(CIP-010)
Cryptographic Cryptographic 2018.01 1/31/2018 1-20 Information Protection
Controls (AZURE) Controls SOP (CIP-011)
2018.01.docx
Asset Management Asset Management 2017.01 7/19/2018 1-31 Information Protection
(AZURE) 2017.01.docx SOP (CIP-011)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 52

Cloud Implementation Guide for NERC Audits

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity with at least one asset identified in CIP-002 containing low impact BES Cyber Systems
shall implement one or more documented cyber security plan(s) for its low impact BES Cyber Systems that
include the sections in Attachment 1. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]
Note: An inventory, list, or discrete identification of low impact BES Cyber Systems or their BES Cyber Assets is
not required. Lists of authorized users are not required.
M2. Evidence shall include each of the documented cyber security plan(s) that collectively include each of the
sections in Attachment 1 and additional evidence to demonstrate implementation of the cyber security plan(s).
Additional examples of evidence per section are located in Attachment 2.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing documented cyber security plans for its low-impact BES Cyber Systems
as stated in CIP-003-6 Attachment 1.

Cloud Provider Responsibility: Yes

NIST 800-53 PL-2 System Security Plan: The Microsoft Azure System Security Plan provides an overview of the security
requirements for Microsoft Azure and the systems and applications within. Additionally, it contains a description of the
security controls that are in place to meet those requirements. The Microsoft Azure System Security Plan is created in
accordance with NIST SP 800-18 R1 Guide for Developing Security Plans for Federal Information Systems, which contains
guidance on security planning. The plan defines the Azure accreditation boundary and describes the operational
environment, security controls that are applicable to the system, and system interconnections.

Section 1. Cyber Security Awareness – NIST 800-53 AT-1 Security Awareness and Training Policy and Procedures:
Microsoft Azure has implemented security awareness and training policy and procedures through the development of a
program that requires all employees to take the required training and any additional training based on individual job
requirements. Microsoft personnel are required to take part in a Microsoft corporate sponsored security-training program
and are to be recipients of periodic security awareness updates. Security education is an on-going process and is
conducted regularly through mandatory and optional trainings, brown bag sessions and external trainings.

For all Microsoft Azure assets, the Azure Education and Awareness SOP was developed as a component of the overall
Azure Awareness and Training Program. The program requires all personnel responsible for Microsoft Azure development
and operations to take essential trainings as well as any additional training based on individual job requirements. These
procedures provide a standard approach, tools, and techniques used to implement and sustain the awareness program.

As described under CIP-004-6 R1.1 and covered by NIST 800-53 AT-2, Microsoft has implemented a security awareness
program called STRIKE that provides monthly e-mail communication to all Azure engineering personnel about security
awareness and allows employees to register for in-person or online security awareness training. STRIKE offers a series of
security training events as well as STRIKE Central, which is a centralized online resource for security awareness, training,
documentation, and community engagement.

Section 2. Physical Security Controls – NIST 800-53 PE-1 Physical and Environmental Protection Policy and Procedures:
Because Registered Entity does not have physical access to any resources in Azure datacenters, all physical and
environmental protection controls are implemented and managed by Azure.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 53

Cloud Implementation Guide for NERC Audits

Microsoft Azure has implemented a physical and environmental policy and procedures to allow for the secure operation
of Azure networks and datacenters. The Microsoft Security Program Policy (MSPP), Physical and Environmental Security
Standard, Asset Classification Standard, and Asset Protection Standard, are all maintained by Azure Infrastructure – C+E
Security State Engineering (SSE) and reviewed and published annually. These documents address the purpose, scope,
roles, responsibilities, compliance requirements, and required coordination among the various Azure organizations that
provide physical and environmental support to Microsoft’s online services. The objective of the physical and
environmental security policy in the Microsoft Security Program Policy (MSPP) is to prevent unauthorized access, damage
or interference to Azure datacenters. For more information, see RSAW narratives for CIP-006-6 requirements.

Section 3.1 Electronic Access Controls – NIST 800-53 SC-7 Boundary Protection: Microsoft Azure implements boundary
protection using controlled devices at the network boundary and at key points within the Microsoft Azure infrastructure.
The overarching principle within Microsoft Azure is to allow only connection and communication that is necessary for
systems to operate, blocking all other ports, protocols and connections by default. Azure employs a defense in depth
strategy for boundary protection, including secure segmentation of network environments through several methods
including VLAN segmentation, ACL restrictions, and encrypted communications for remote connectivity (SSL VPN and
Remote Desktop Gateway access) to the environment. Furthermore, techniques like control plane policing security are
used to isolate services. The key boundaries included as part of Azure’s Infrastructure include the Global Infrastructure
LAN used to support infrastructure supporting services and the external boundary of the RD Gateway and SSL VPN
boundary used to support remote access to the environment.

Section 3.2 Electronic Access Controls for Dial-up Connectivity: Not applicable because dial-up access is not provided
through Microsoft Azure.

Section 4. Cyber Security Incident Response – NIST 800-53 IR-1 Incident Response Policy and Procedures: Microsoft Azure
has implemented the incident response policy control through the publishing of the Microsoft Security Program Policy
(MSPP). Azure addresses its incident management policy as part of the Microsoft Security Program Policy (MSPP). The
policy, addresses the following:
• Purpose of providing rules and requirements to applicable personnel
• Scope covering properties and services
• Roles and responsibilities for those involved with the policy
• Management commitment through coordination with security organizations, property security groups, and Microsoft
corporate functions
• Compliance by requiring all employees to adhere to the policy and applicable standards and follow approved procedures

Microsoft Azure has developed and implemented the Microsoft Azure Incident Management Standard Operating
Procedure (SOP). The SOP provides a high-level approach for how the incident response capability fits into the overall
organization and describes the structure and organization of the incident response capabilities. The SOP covers:

• Identification, classification, and response to cyber security incidents.

• Process used by Microsoft to determine if an incident is reportable (see Section 4.2.2. Escalation and Notification).
• Roles and responsibilities.
• Incident handling procedures.
• Testing of the cyber security incident plan at least annually.
• Updating the cyber security incident plan monthly following the review of all impacting incidents for the previous month.
The incident response plan is revised to address changes or problems encountered during plan implementation, execution,
or testing.

For more information, see RSAW narratives for CIP-008-5 requirements.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 54

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 514 Covers NIST 800-53 PL-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 171 Covers NIST 800-53 AT-1
“ “ “ “ 172-175 Covers NIST 800-53 AT-2
Education and Cloud and Enterprise 2018.01 2/28/2018 1-10 Covers Section 1. Cyber
Awareness 2018.01 Security Education & Security Awareness in
(C+E Security).docx Awareness SOP Attachment 1.
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 483 Covers NIST 800-53 PE-1
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Datacenter Physical Standard Operating 13.4 6/28/2018 1-185 Covers Section 2. Physical
Security SOP for Procedures for Security Controls in
Operations v13.4.docx Operations Attachment 1.
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 619-622 Covers NIST 800-53 SC-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 406 Covers NIST 800-53 IR-1
Incident Management Incident Management 2018.01 8/23/2018 1-42 Covers Section 4. Cyber
SOP 2018.01.docx SOP Security Incident Response
in Attachment 1.

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall identify a CIP Senior Manager by name and document any change within 30
calendar days of the change. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
M3. An example of evidence may include, but is not limited to, a dated and approved document from a high level
official designating the name of the individual identified as the CIP Senior Manager.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for identifying a CIP Senior Manager within its organization and documenting any change
within 30 calendar days of the change.

Cloud Provider Responsibility: No

NIST 800-53 CA-6 Security Authorization: Microsoft has identified the Azure Information System Owner, Information
System Management Point of Contact, Information System Technical Point of Contact, and Information System Security
Officer as part of the FedRAMP authorization. These individuals are named in Table 3-1, Table 5-1, Table 5-2, and Table 6-
MICROSOFT CONFIDENTIAL – NDA REQUIRED 55
Cloud Implementation Guide for NERC Audits

1 of the Azure System Security Plan, and they or their designated representatives work with the FedRAMP Joint
Authorization Board (JAB) or other customer entities to authorize operation of the Azure system. These designations
address Microsoft responsibilities for naming system owners pursuant to FedRAMP requirements. Microsoft does not
have the equivalent of a CIP Senior Manager on staff; this assignment is specific to Registered Entities.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 6-8 Designate Microsoft
Moderate System Moderate System officials per FedRAMP
Security Plan v3.05.pdf Security Plan System Security Plan

R4 Supporting Evidence and Documentation

R4. The Responsible Entity shall implement a documented process to delegate authority, unless no delegations are
used. Where allowed by the CIP Standards, the CIP Senior Manager may delegate authority for specific actions
to a delegate or delegates. These delegations shall be documented, including the name or title of the delegate,
the specific actions delegated, and the date of the delegation; approved by the CIP Senior Manager; and
updated within 30 days of any change to the delegation. Delegation changes do not need to be reinstated with
a change to the delegator. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]
M4. An example of evidence may include, but is not limited to, a dated document, approved by the CIP Senior
Manager, listing individuals (by name or title) who are delegated the authority to approve or authorize
specifically identified items.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing a process to delegate authority within its organization.

Cloud Provider Responsibility: No

NIST 800-53 CA-6 Security Authorization: Microsoft has identified the Azure Information System Owner, Information
System Management Point of Contact, Information System Technical Point of Contact, and Information System Security
Officer as part of the FedRAMP authorization. There are no provisions in the FedRAMP System Security Plan to delegate
authority; instead, this requirement is part of Registered Entity’s responsibility.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 56

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 6-8 Designate Microsoft
Moderate System Moderate System officials per FedRAMP
Security Plan v3.05.pdf Security Plan System Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 57

Cloud Implementation Guide for NERC Audits

CIP-004-6 – Cyber Security – Personnel & Training

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented processes that collectively include each of
the applicable requirement parts in CIP-004-6 Table R1 – Security Awareness Program. [Violation Risk Factor:
Lower] [Time Horizon: Operations Planning].
M1. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-004-6Table R1 – Security Awareness Program and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R1 Part 1.1

CIP-004-6 Table R1 – Security Awareness Program

Part Applicable Systems Requirements Measures

1.1 High Impact BES Cyber Systems Security awareness that, at least An example of evidence may include, but is
once each calendar quarter, not limited to, documentation that the
Medium Impact BES Cyber Systems
reinforces cyber security practices quarterly reinforcement has been provided.
(which may include associated Examples of evidence of reinforcement may
physical security practices) for the include, but are not limited to, dated copies
Responsible Entity’s personnel who of information used to reinforce security
have authorized electronic or awareness, as well as evidence of
authorized unescorted physical distribution, such as:
access to BES Cyber Systems. • direct communications (for
example, e-mails, memos,
computer-based training); or
• indirect communications (for
example, posters, intranet, or
brochures); or
• management support and
reinforcement (for example,
presentations or meetings).

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for providing security awareness training to its employees and vendors at least once every
calendar quarter to reinforce cyber security practices for personnel with authorized electronic access to cloud-based and
on-premises resources.

Cloud Provider Responsibility: Yes

NIST 800-53 AT-2 Security Awareness Training: FedRAMP requires that security training be administered at least annually.
However, Microsoft has implemented a security awareness program called STRIKE that provides monthly e-mail
communication to all Azure engineering personnel about security awareness and allows employees to register for in-
person or online security awareness training. STRIKE offers a series of security training events as well as STRIKE Central,
which is a centralized online resource for security awareness, training, documentation, and community engagement.
STRIKE events are comprised of:

MICROSOFT CONFIDENTIAL – NDA REQUIRED 58

Cloud Implementation Guide for NERC Audits

• STRIKE Confidential – a large 1,500+ participant event which includes a series of Microsoft Confidential presentations.
This event is offered twice a year.
• STRIKE Day – a single day multi-track event where participants are able to self-select specific track sessions to attend.
This event is offered six times a year.
• STRIKE Expo – additional offerings designed to meet a specific security need or group of participants. These events are
offered as needed throughout the year.

The following STRIKE security training schedule shown for FY19 is representative of STRIKE annual cadence:

Event Date Location

STRIKE Confidential August 27, 2018 Microsoft Conference Center
STRIKE Days September 9, 2018 Microsoft Conference Center
STRIKE Days October 8, 2018 Microsoft Conference Center
STRIKE Days November 9, 2018 Microsoft Conference Center
STRIKE Confidential February 22, 2019 Microsoft Conference Center
STRIKE Days March 13, 2019 Learning Center B92
STRIKE Days April 15, 2019 Microsoft Conference Center
STRIKE Days May 7, 2019 Learning Center B92

Because of Azure STRIKE monthly communication cadence about security awareness and information about available
security training events and online training resources, Microsoft exceeds the NERC requirement for quarterly
reinforcement of cyber security practices.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 172-175 Covers NIST 800-53 AT-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Education and Cloud and Enterprise 2018.01 2/28/2018 1-10 Personnel and Training (CIP-
Awareness 2018.01 Security Education & 004)
(C+E Security).docx Awareness SOP

MICROSOFT CONFIDENTIAL – NDA REQUIRED 59

Cloud Implementation Guide for NERC Audits

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement one or more cyber security training program(s) appropriate to
individual roles, functions, or responsibilities that collectively includes each of the applicable requirement parts
in CIP-004-6 Table R2 – Cyber Security Training Program. [Violation Risk Factor: Lower] [Time Horizon:
Operations Planning]
M2. Evidence must include the training program that includes each of the applicable requirement parts in CIP-004-6
Table R2 – Cyber Security Training Program and additional evidence to demonstrate implementation of the
program(s).

R2 Part 2.1

CIP-004-6 Table R2 – Cyber Security Training Program

Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems and Training content on: Examples of evidence may include,
their associated: 2.1.1. Cyber security policies; but are not limited to, training
1. EACMS; and 2.1.2. Physical access controls; material such as power point
2. PACS 2.1.3. Electronic access controls; presentations, instructor notes,
2.1.4. The visitor control program; student notes, handouts, or other
Medium Impact BES Cyber Systems
2.1.5. Handling of BES Cyber System training materials.
with External Routable Connectivity
Information and its storage;
and their associated:
2.1.6. Identification of a Cyber Security
1. EACMS; and
Incident and initial notifications in
2. PACS
accordance with the entity’s
incident response plan;
2.1.7. Recovery plans for BES Cyber
Systems;
2.1.8. Response to Cyber Security
Incidents; and
2.1.9. Cyber security risks associated with
a BES Cyber System’s electronic
interconnectivity and
interoperability with other Cyber
Assets, including Transient Cyber
Assets, and with Removable Media.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for developing training content for its own employees. Training should consider all
controls that are the responsibility of the customer, including controls related to shared touch points in the Azure
authorization boundary and any customer applications leveraging Azure infrastructure. Registered Entities should review
Azure Operational Security best practices.

Cloud Provider Responsibility: Yes

NIST 800-53 AT-2 Security Awareness Training: Microsoft provides security awareness activities throughout the course of
a year to all employees, vendors and contingent staff. The annual Security and Privacy Foundations training includes basic
level training on how to detect, report and implement best practices to safeguard Microsoft and its customers. This course
MICROSOFT CONFIDENTIAL – NDA REQUIRED 60
Cloud Implementation Guide for NERC Audits

also covers the security requirements and expectations for elevated privileges in production environments. Engineering
personnel participate in on-going role-based security training through the STRIKE program. STRIKE provides regular 200-
400 level sessions, labs and online courses to engage, educate and empower engineers to securely design and operate
services.

STRIKE offers a series of security training events throughout the year as well as STRIKE Central, which is a centralized online
resource for security awareness, training, documentation, and community engagement. As of Dec-2018, STRIKE online
security training (internal link) contains 32 courses covering all topics listed above in CIP-004-6 R2.1 except for:

• 2.1.9 Cyber security risks associated with a BES Cyber System’s electronic interconnectivity and interoperability with
other Cyber Assets, including Transient Cyber Assets, and with Removable Media.

Registered Entities would be solely responsible for administering this training to their employees. Microsoft does not
inspect, approve, or monitor customer applications in Azure. Microsoft does not know how a BES Cyber System is designed
and operated. Neither Azure nor Azure Government constitutes a BES Cyber System or BES Cyber Asset. Microsoft
engineers are not required to understand how customer applications deployed in Azure are interconnected or what
dependencies they have.

NIST 800-53 CP-3 Contingency Training: All employees with a contingency planning role receive training within 10 days of
being assigned this role and on an annual basis (rolling 365 from the last training date). Upon completion of the training,
each employee certifies that they have been trained electronically via email (e-signature) which is then stored by the
Business Continuity Management System (BCMS) operator for verification. The process is documented in the Azure
Business Continuity and Disaster Recovery SOP. Evidence of training is stored on the Azure BCM SharePoint Site under
the training folder.

Incident managers receive training in the incident response workflow following the Incident Management SOP. Disaster
recovery follows the same workflow as incident response. Service team Business Continuity Management (BCM) owners
and crisis communications managers receive training by participating in simulated events, including regular recovery
testing and disaster recovery drills. This training occurs at least annually and prior to assuming a contingency-related role,
as well as whenever system changes occur.

NIST 800-53 IR-2 Incident Response Training: As documented in the Microsoft Azure Incident Management SOP, managers
ensure that all personnel, including new hires, are trained on incident handling procedures and protocols consistent with
assigned roles and responsibilities. Security training, including specifics on incident response, is provided annually to all
Azure Infrastructure personnel (employees, contractors, and third party providers) as a part of the Microsoft security
awareness training. Service team and feature team on-call personnel receive additional, in-place, training on their incident
response roles and responsibilities through mandatory exercises conducted annually.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 174 Covers NIST 800-53 AT-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 335 Covers NIST 800-53 CP-3
“ “ “ “ 408-409 Covers NIST 800-53 IR-2
MICROSOFT CONFIDENTIAL – NDA REQUIRED 61
Cloud Implementation Guide for NERC Audits

Incident Management Incident Management 2018.01 8/23/2018 25-26 Covers CIP-004-6 R2.1.6 and
SOP 2018.01.docx SOP R2.1.8

R2 Part 2.2

CIP-004-6 Table R2 – Cyber Security Training Program

Part Applicable Systems Requirements Measures

2.2 High Impact BES Cyber Systems and Require completion of the training Examples of evidence may include,
their associated: specified in Part 2.1 prior to granting but are not limited to, training
1. EACMS; and authorized electronic access and records and documentation of
2. PACS authorized unescorted physical when CIP Exceptional
access to applicable Cyber Assets, Circumstances were invoked.
Medium Impact BES Cyber Systems with except during CIP Exceptional
External Routable Connectivity and Circumstances.
their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for training its employees and vendors as necessary, as well as tracking the completion of
mandatory training programs.

Cloud Provider Responsibility: Yes

Microsoft requires all Azure employees to complete training as part of their onboarding process and before access to
Azure production systems is granted. This requirement is documented in the Education and Awareness SOP, Section 1.3
Compliance Requirement, Page 3.

2) The training shall be conducted:

a. as part of the initial training for new users before authorizing access to the system or performing assigned duties; or
b. when required by system changes; or
c. at least annually.

NIST 800-53 AT-3 Role-Based Security Training: FedRAMP requires under AT-03 that the organization provide role-based
security training to personnel with assigned security roles and responsibilities before authorizing access to the information
system or performing assigned duties. Azure security training is classified into one of two types: Role-Based and Required.

Role-Based Training
Role-Based training is mandatory security and awareness education that is deemed helpful in the facilitation of
understanding security processes and procedures for a particular role an individual is placed in and is directly related to
the job responsibilities of the individual. Role-Based training is offered to full-time employees and suppliers. Role-Based
training includes the STRIKE program for engineering disciplines providing Level 200-400 security training and best
practices.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 62

Cloud Implementation Guide for NERC Audits

Required Training
Required training is mandatory security and awareness education that Microsoft has specifically identified and defined as
appropriate for Azure personnel based upon their organization. Required annual training includes:
• Security and Privacy Foundations for new hires and non-engineering FTEs
• STRIKE program for engineering FTEs

As part of the security awareness and training program, Microsoft defines required and elective role-based training to
help facilitate understanding of security processes and procedures for an individual’s role and responsibilities before
authorizing access to Microsoft Azure’s Infrastructure.

NIST 800-53 AT-4 Security Training Records: Microsoft Azure utilizes Success Factors Learning Management System (LMS)
to document and monitor security training. The LMS provides reporting to effectively manage and track security training
participation. Each employee has access to their own account, which includes courses taken and elective courses that are
suggested. A report can be generated from this tool to show what courses were taken by a specific employee. Security
training records for the training described in AT-3 are documented, monitored, and retained for at least five years.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Education and Cloud and Enterprise 2018.01 2/28/2018 3 CIP-004-6 R2.2
Awareness 2018.01 Security Education &
(C+E Security).docx Awareness SOP
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 175-177 Covers NIST 800-53 AT-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 177-178 Covers NIST 800-53 AT-4

MICROSOFT CONFIDENTIAL – NDA REQUIRED 63

Cloud Implementation Guide for NERC Audits

R2 Part 2.3

CIP-004-6 Table R2 – Cyber Security Training Program

Part Applicable Systems Requirements Measures

2.3 High Impact BES Cyber Systems and Require completion of the training Examples of evidence may
their associated: specified in Part 2.1 at least once include, but are not limited to,
1. EACMS; and every 15 calendar months. dated individual training
2. PACS records.

Medium Impact BES Cyber Systems

with External Routable Connectivity
and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring its employees undergo required training at least once every 15 months.

Cloud Provider Responsibility: Yes

NIST 800-53 AT-2 Security Awareness Training: FedRAMP requires that security training be administered at least annually.
Microsoft requires all Azure employees to complete the following training as part of their onboarding process and then
annually thereafter to maintain compliance with security training requirements.

• Security and Privacy Foundations course – Azure new hire personnel are required to take the Security Foundations
course within 30 days of employment, and annually thereafter for non-engineering personnel.
• STRIKE – Azure engineering personnel are required to participate in STRIKE training at least annually through in-person
events, sessions, labs, and online courses. STRIKE provides Level 200-400 training to engage, educate, and empower
engineers to securely design and operate services.
• Standards of Business Conduct Training – an online course updated annually, providing information intended to raise
awareness in the areas of anti-trust, corruption, unauthorized entry/theft, business policy, and applicable laws and
regulations. This training is required during orientation and annually thereafter for all employees.

Microsoft also administers security awareness activities throughout the course of a year to all employees, vendors and
contingent staff through “brown bag sessions”, seminars, distribution lists, external trainings and posters that are
distributed and published through all the buildings housed by Microsoft employees, vendors, and contingent staff.
Security training is also required when there is a significant change to the system environment. Employees can check their
security training status via personalized STRIKE security compliance dashboards. The following security education is
offered to Azure personnel:

Type Offering Audience Frequency Description

Basic Security Supplier Code of Suppliers On hire Online course providing content to Suppliers
Training Conduct (SCoC) within the US and Canada meeting the
security awareness requirements prior to
MICROSOFT CONFIDENTIAL – NDA REQUIRED 64
Cloud Implementation Guide for NERC Audits

service access.
Standards of FTE Annual Online course updated annually, providing
Business Conduct information intended to raise awareness in
the areas of anti-trust, corruption,
unauthorized entry/theft, business policy,
and applicable laws and regulations.
Security & Privacy FTE New Hires On hire Required for all FTE new hires within 30 days
Foundations of hire and prior to assignment.
Non- Engineering Annual All non-engineering disciplines are required
to take the annually updated Security &
Privacy Foundations course.
Engineering Annual Required annually or in combination with
STRIKE.
Suppliers out of Annual Suppliers outside the scope of the SCoC
SCoC scope program are required to completed Security
and Privacy Foundations training.
Role Based STRIKE Engineering Twice a Large 1,500+ participant event which includes
Security Confidential year a series of “Microsoft confidential”
Training presentations.
STRIKE Day Engineering Six times a Single day multi-track event where
year participants are able to self-select specific
track sessions to attend.
STRIKE Expo Engineering As needed Additional offerings designed to meet a
specific security need or group of
participants.
Security Security FTE and Suppliers Quarterly Training on recognizing and reporting
Awareness Awareness potential indicators of insider threat.
Campaigns

NIST 800-53 AT-3 Role-Based Security Training: As part of the Azure Awareness and Training program, personnel are
required to take Role-Based and Required security and awareness training before access is granted to Microsoft Azure,
and annually thereafter. The Microsoft System Administrator training is tracked in Learning Central and personnel are
required to retake it annually.

NIST 800-53 AT-4 Security Training Records: Microsoft Azure utilizes Success Factors Learning Management System (LMS)
to document and monitor security training. The LMS provides reporting to effectively manage and track security training
participation. Each employee has access to their own account, which includes courses taken and elective courses that are
suggested. A report can be generated from this tool to show what courses were taken by a specific employee. Security
training records for the training described in AT-3 are documented, monitored, and retained for at least five years.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 172-175 Covers NIST 800-53 AT-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
MICROSOFT CONFIDENTIAL – NDA REQUIRED 65
Cloud Implementation Guide for NERC Audits

“ “ “ “ 175-177 Covers NIST 800-53 AT-3

“ “ “ “ 177-178 Covers NIST 800-53 AT-4

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall implement one or more documented personnel risk assessment program(s) to
attain and retain authorized electronic or authorized unescorted physical access to BES Cyber Systems that
collectively include each of the applicable requirement parts in CIP-004-6 Table R3 – Personnel Risk Assessment
Program. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]
M3. Evidence must include the documented personnel risk assessment programs that collectively include each of the
applicable requirement parts in CIP-004-6 Table R3 – Personnel Risk Assessment Program and additional
evidence to demonstrate implementation of the program(s).

R3 Part 3.1

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Applicable Systems Requirements Measures

3.1 High Impact BES Cyber Systems and Process to confirm identity. An example of evidence may
their associated: include, but is not limited to,
1. EACMS; and documentation of the Responsible
2. PACS Entity’s process to confirm
identity.
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for confirming the identity of its users prior to granting them access to internal systems
and resources provisioned in Azure.

Cloud Provider Responsibility: Yes

NIST 800-53 IA-5 Authenticator Management: The Human Resource (HR) database, HeadTrax, is the authoritative source
for verifying the employee, employment status, and identity of the individual receiving the authenticator. Identifiers are
established for each user through unique user IDs based on HR employee ID numbers and passwords managed via the
Microsoft corporate Active Directory (AD). User identifiers are distributed to Azure personnel during the hiring process.

As described in the Personnel Screening Standard Operating Procedure (SOP), all new employees are subject to the
Microsoft Background Check, which includes identity verification as part of the 7-point verification process, including:

• Employment history check for the previous seven years

MICROSOFT CONFIDENTIAL – NDA REQUIRED 66
Cloud Implementation Guide for NERC Audits

• Education check (highest degree obtained)

• Social Security Number (SSN) check
• Criminal history check for the previous seven years
• Office of Foreign Assets Control List (OFAC) check
• Bureau of Industry and Security List (BIS) check
• Office of Defense Trade Controls Debarred Persons List check

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 382 Covers NIST 800-53 IA-5
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Personnel Screening Personnel Screening 2018.01 3/12/2018 9-10 CIP-004-6 R3
(AZURE) 2018.01.docx SOP

R3 Part 3.2

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Applicable Systems Requirements Measures

3.2 High Impact BES Cyber Systems Process to perform a seven-year An example of evidence may include,
and their associated: criminal history records check as part but is not limited to, documentation of
1. EACMS; and of each personnel risk assessment the Responsible Entity’s process to
2. PACS that includes: perform a seven-year criminal history
3.2.1 current residence, regardless records check.
Medium Impact BES Cyber of duration; and
Systems with External Routable 3.2.2 other locations where, during
Connectivity and their the seven years immediately
associated: prior to the date of the
1. EACMS; and criminal history records
2. PACS check, the subject has
resided for six consecutive
months or more.
If it is not possible to perform a full
seven-year criminal history records
check, conduct as much of the seven-
year criminal history records check as
possible and document the reason the
full seven-year criminal history records
check could not be performed.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 67

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for determining and implementing screening requirements for its own personnel prior to
granting them access to internal systems and resources deployed in Azure, including a process to perform a 7-yr criminal
history records check.

Cloud Provider Responsibility: Yes

NIST 800-53 PS-3 Personnel Screening: The Microsoft Human Resources (HR) department conducts background checks
and enforces the screening policies for all personnel (including vendors). Background checks are required for new hires or
personnel transferring to positions that involve potential access to Customer Data. The Microsoft Background Check
includes the following:

• Employment history check for the previous seven years

• Education check (highest degree obtained)
• Social Security Number (SSN) check
• Criminal history check for the previous seven years
• Office of Foreign Assets Control List (OFAC) check
• Bureau of Industry and Security List (BIS) check
• Office of Defense Trade Controls Debarred Persons List check

The process to perform personnel background screening, including a 7-yr criminal history records check is described in the
Personnel Background Screening SOP.

Personnel background screening is conducted by Truescreen on behalf of Microsoft. The process includes a 7-yr criminal
history records check as specified by Microsoft, as well as verification of the current and prior residences over the past 7
years. As part of the Social Security Number verification, Truescreen has implemented a Fair Credit Reporting Act (FCRA)-
compliant search using bureau data to help confirm applicant’s identity, reveal his or her address history, and uncover
alias or AKA names. The results are compared against the applicant’s data, including the 7-yr criminal records search, to
identify any discrepancies. More information about the process is available from Truescreen.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 530 Covers NIST 800-53 PS-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Personnel Screening Personnel Screening 2018.01 3/12/2018 9 CIP-004-6 R3
(AZURE) 2018.01.docx SOP

MICROSOFT CONFIDENTIAL – NDA REQUIRED 68

Cloud Implementation Guide for NERC Audits

R3 Part 3.3

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Applicable Systems Requirements Measures

3.3 High Impact BES Cyber Systems and Criteria or process to evaluate An example of evidence may
their associated: criminal history records checks for include, but is not limited to,
1. EACMS; and authorizing access. documentation of the
2. PACS Responsible Entity’s process to
evaluate criminal history
Medium Impact BES Cyber Systems records checks.
with External Routable Connectivity
and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for determining and implementing screening criteria or process for its own personnel prior
to granting them access to customer systems.

Cloud Provider Responsibility: Yes

NIST 800-53 PS-3 Personnel Screening: The Microsoft Human Resources (HR) department conducts background checks
and enforces the screening policies for all personnel (including vendors). Criminal history records check is documented as
part of this process.

The criteria and process for evaluating the results of personnel background screening, including the criminal history
records checks for authorizing access, are described in the Personnel Screening SOP. Cloud Screen typically takes 7
business days to complete from the time the employee endorses the online agreement and submits all required
information. If anything of concern is identified through Cloud Screen, the employee will receive a letter from Global
Security outlining the steps to meet with a representative from their team to provide the employee with information
about the issue of concern. Global Security will then work with HR to evaluate the issue and make a pass/fail decision. If
an individual fails the Cloud Screen, they may be ineligible to work at Microsoft and could be terminated from
employment.

Every case is reviewed and adjudicated on an individual basis with many variables to consider such as:

• Type of conviction – felony vs. misdemeanor

• Number of convictions/charges
• Proximity – e.g. was this 7 years ago or is it a pending case
• Job relatedness – e.g. embezzlement vs. DUI

These parameters are applicable to the criminal component of the Cloud Screen. For new hire background checks,
education and employment history are two other major components that can lead to fail decisions based on negative
information or other discrepancies discovered.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 69

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 530 Covers NIST 800-53 PS-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Personnel Screening Personnel Screening 2018.01 3/12/2018 12 CIP-004-6 R3
(AZURE) 2018.01.docx SOP

R3 Part 3.4

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Applicable Systems Requirements Measures

3.4 High Impact BES Cyber Systems Criteria or process for verifying that An example of evidence may
and their associated: personnel risk assessments include, but is not limited to,
1. EACMS; and performed for contractors or service documentation of the Responsible
2. PACS vendors are conducted according to Entity’s criteria or process for
Parts 3.1 through 3.3. verifying contractors or service
Medium Impact BES Cyber vendors personnel risk assessments.
Systems with External Routable
Connectivity and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for determining and implementing screening criteria or process for its own personnel
including contractors and service vendors prior to granting them access to customer systems.

Cloud Provider Responsibility: Yes

NIST 800-53 PS-3 Personnel Screening: The Microsoft Human Resources (HR) department conducts background checks
and enforces the screening policies for all personnel (including vendors). Vendor staff with potential access to Customer
Data are required to sign a background screening addendum with Microsoft and complete background screening before
they can be issued credentials via the Microsoft HR HeadTrax system. Microsoft managers are required to include
screening requirements in their respective Statement of Work (SOW) documents with vendors.

The criteria and process for evaluating the results of personnel background screening for contractors or service vendors
are described in the Personnel Screening SOP. Cloud Screen typically takes 7 business days to complete from the time the
employee endorses the online agreement and submits all required information. If anything of concern is identified
through Cloud Screen, the vendor will receive a letter from Global Security outlining the steps to meet with a
MICROSOFT CONFIDENTIAL – NDA REQUIRED 70
Cloud Implementation Guide for NERC Audits

representative from their team to provide the vendor with information about the issue of concern. Global Security will
then work with HR to evaluate the issue and make a pass/fail decision. If an individual fails the Cloud Screen, they may be
ineligible to work at Microsoft and their contract could be terminated. Background screening requirements are clearly
identified to vendors as part of the Statement of Work (SOW).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 530 Covers NIST 800-53 PS-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Personnel Screening Personnel Screening 2018.01 3/12/2018 12 CIP-004-6 R3
(AZURE) 2018.01.docx SOP

R3 Part 3.5

CIP-004-6 Table R3 – Personnel Risk Assessment Program

Part Applicable Systems Requirements Measures

3.5 High Impact BES Cyber Systems and Process to ensure that individuals with An example of evidence may
their associated: authorized electronic or authorized include, but is not limited to,
1. EACMS; and unescorted physical access have had a documentation of the
2. PACS personnel risk assessment completed Responsible Entity’s process for
according to Parts 3.1 to 3.4 within the ensuring that individuals with
Medium Impact BES Cyber Systems last seven years. authorized electronic or
with External Routable Connectivity authorized unescorted physical
and their associated: access have had a personnel risk
assessment completed within
1. EACMS; and
the last seven years.
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that personnel risk assessment has been completed according to the
established process and criteria.

Cloud Provider Responsibility: Yes

NIST 800-53 PS-3 Personnel Screening: The Microsoft Human Resources (HR) department conducts background checks
and enforces the screening policies for all personnel (including vendors). The process to ensure that employees and
vendors with authorized electronic or authorized unescorted physical access have had a personnel background screen
completed every 2 years is described in the Personnel Screening SOP. Microsoft 2-yr re-screening requirement exceeds
that specified in CIP-004-06 R3.5, which mandates a 7-yr horizon.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 71
Cloud Implementation Guide for NERC Audits

The following table summarizes Microsoft background screening requirements and time horizons:

Applicable screening and Environment Frequency Description

background check
Background Check Azure Upon employment • Education history (highest degree)
Cloud Screen Azure Gov • Employment history (7-yr history)
Every 2 years • Social Security Number search
• Criminal records check (7-yr history)
• Office of Foreign Assets Control (OFAC) list
• Bureau of Industry and Security (BIS) list
• Office of Defense Trade Controls debarred
persons list
US citizenship Azure Gov Upon employment • Verification of US citizenship

The Microsoft Background Check is completed upon hire to Microsoft. It is based on a 7-point check, including Education
and Employment verification. The Microsoft Cloud Screen is the same as the Microsoft Background Check with the
omission of the Education and Employment verification. The Microsoft Cloud Screen is performed upon hire or transfer
into the role and then every 2 years thereafter. It is required for all Azure and Azure Government employees in the United
States with potential access to Customer Data.

Personnel risk assessment is conducted upon background screening completion. If anything of concern is identified, the
employee or vendor will receive a letter from Microsoft Global Security outlining the steps to meet with a representative
from their team to provide the employee or vendor with information about the issue of concern. Global Security will then
work with HR to evaluate the issue and make a pass/fail decision. If an individual fails the Cloud Screen, they may be
ineligible to work at Microsoft and could be terminated from employment.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 530 Covers NIST 800-53 PS-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Personnel Screening Personnel Screening 2018.01 3/12/2018 9 CIP-004-6 R3
(AZURE) 2018.01.docx SOP

MICROSOFT CONFIDENTIAL – NDA REQUIRED 72

Cloud Implementation Guide for NERC Audits

R4 Supporting Evidence and Documentation

R4. Each Responsible Entity shall implement one or more documented access management program(s) that
collectively include each of the applicable requirement parts in CIP-004-6 Table R4 – Access Management
Program. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning and Same Day Operations].
M4. Evidence must include the documented processes that collectively include each of the applicable requirement
parts in CIP-004-6 Table R4 – Access Management Program and additional evidence to demonstrate that the
access management program was implemented as described in the Measures column of the table.

R4 Part 4.1

CIP-004-6 Table R4 – Access Management Program

Part Applicable Systems Requirements Measures

4.1 High Impact BES Cyber Systems and Process to authorize based on need, An example of evidence may
their associated: as determined by the Responsible include, but is not limited to,
1. EACMS; and Entity, except for CIP Exceptional dated documentation of the
2. PACS Circumstances: process to authorize electronic
access, unescorted physical access
4.1.1 Electronic access;
Medium Impact BES Cyber Systems in a Physical Security Perimeter,
with External Routable Connectivity 4.1.2 Unescorted physical access into and access to designated storage
and their associated: a Physical Security Perimeter; and locations, whether physical or
electronic, for BES Cyber System
1. EACMS; and 4.1.3 Access to designated storage
Information.
2. PACS locations, whether physical or
electronic, for BES Cyber System
Information.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for authorizing electronic access to its applications and data hosted in Azure and on-
premises. Access control for hosted services and storage accounts is governed by the Azure subscription. The ability to
authenticate with the customer’s federated identity associated with the subscription grants full control to all the hosted
services and storage accounts within that subscription. Azure Active Directory helps safeguard access to data and
applications while meeting user demand for a simple sign-on process. It delivers strong authentication via a range of easy
verification options—phone call, text message, or mobile app notification—allowing users to choose the method they
prefer. Customers use Multi-Factor Authentication to protect access to sensitive information and to help protect their
organization from malicious attacks. Customers should review Azure Identity Management and access control security
best practices.

Cloud Provider Responsibility: Yes

Registered Entities can use Azure Customer Lockbox to control how a Microsoft engineer accesses their data for support
scenarios. As part of the Support workflow, Microsoft Engineer may require elevated access to Customer Data. Azure
Lockbox puts the customer in charge of that decision by enabling the customer to Approve/Deny such elevated requests.
Azure Lockbox is an extension of the Just in Time (JIT) workflow and also comes with full audit logging enabled. It is
important to note that Azure Lockbox capability is not required for support cases that do not involve access to Customer

MICROSOFT CONFIDENTIAL – NDA REQUIRED 73

Cloud Implementation Guide for NERC Audits

Data. For the majority of support scenarios, access to Customer Data is not needed and the workflow should not require
Azure Lockbox.

NIST 800-53 AC-2 Account Management: Microsoft Azure leverages Microsoft corporate Active Directory (AD), managed
by Core Services Engineering (CSE, formerly MSIT), to control access to key information systems. Azure personnel are
assigned unique corporate AD accounts by CSE as part of a standard new employee onboarding to Microsoft. From a
Microsoft Azure perspective, ‘new user accounts’ refers to accounts of existing Microsoft users using their unique
corporate AD accounts, who require access to Azure systems, including production systems containing customer compute
and storage resources. New user account requests and access approvals are managed through the internal account
management tool RAMWeb, which provides an automated workflow to track the process from account request, approval,
creation, modification, and deletion. All Azure access is granted based on personnel employment verification and business
justification. Membership to access control security groups is limited based on job function (role-based access) within
RAMWeb.

By default, accounts do not have active elevated permissions to the production environment. Such access is not needed
to operate Azure and Azure Government. Elevation requires the user to request temporary Just In Time (JIT) access
through the JIT portal. Temporary JIT access is tracked by the live site team (WALS) in Team Foundation Services (TFS) and
is revoked by WALS prior to closing of the service request. JIT access is short lived and terminated per the JIT policy settings
for the access request.

NIST 800-53 PE-2 Physical Access Authorization: Access to a Microsoft datacenter must be approved by the Data Center
Management (DCM) team through the Data Center Access Tool (DCAT). DCAT is the authoritative source listing all
personnel with authorized access to a specific datacenter. DCAT is linked with the datacenter’s physical security access
control devices and authorizes access based on access levels that are approved by the DCM team. Access levels are
assigned in DCAT to either a user’s Microsoft issued badge or a temporary access badge that is assigned at the datacenter
by the Control Room Supervisor (CRS). Access levels are approved by the DCM team. Besides credentials assigned to
physical badges, some areas of datacenter require enrollment of the user’s biometric data (hand geometry or fingerprint),
as well as badge authentication to gain authorized entry.

The Azure DCM of a leased datacenter is responsible for conducting the same access review as they would for a fully-
managed Azure datacenter. Instead of reviewing the access levels for the entire datacenter, the DCM would request the
access list for the Microsoft areas from the datacenter's security team. The DCM is responsible for ensuring that both the
landlord's access system and DCAT reflect the same data. At a leased datacenter, DCAT is still considered the authoritative
source for access to Microsoft areas within the datacenter. All access request approvals are first processed in DCAT and
then emailed to the leased datacenter's security team. The leased datacenter's security team only authorizes access to
Microsoft areas to individuals with an approved DCAT request. Besides credentials assigned to physical badges, some
areas of datacenter require two- factor authentication employing the user’s biometric data (hand geometry or fingerprint),
as well as badge authentication to gain authorized entry.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 103-106 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 485 Covers NIST 800-53 PE-2
MICROSOFT CONFIDENTIAL – NDA REQUIRED 74
Cloud Implementation Guide for NERC Audits

R4 Part 4.2

CIP-004-6 Table R4 – Access Management Program

Part Applicable Systems Requirements Measures

4.2 High Impact BES Cyber Systems and Verify at least once each calendar Examples of evidence may include,
their associated: quarter that individuals with active but are not limited to:
1. EACMS; and electronic access or unescorted
• Dated documentation of the
2. PACS physical access have authorization
verification between the system
records.
generated list of individuals who
Medium Impact BES Cyber Systems have been authorized for access
with External Routable Connectivity (i.e., workflow database) and a
and their associated: system generated list of personnel
1. EACMS; and who have access (i.e., user account
2. PACS listing), or
• Dated documentation of the
verification between a list of
individuals who have been
authorized for access (i.e.,
authorization forms) and a list of
individuals provisioned for access
(i.e., provisioning forms or shared
account listing).

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for reviewing access authorizations on a quarterly basis.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-2 Account Management: The service team's management identifies service team personnel who should
be given authorization to access the system and specifies the type of privilege each service team personnel should have
based on their role. Role-Based Access Control (RBAC) is used to identify and control the access privileges of each service
team personnel. Access privileges vary depending on the role a specified service team member will assume within the
service team. Access privileges are defined in the RAMWeb tool or Account Management Tool and enforced by Active
Directory. Accounts that have access to Microsoft Azure systems must be reviewed every 90 days by Microsoft Azure
group owners.

NIST 800-53 PE-2 Physical Access Authorizations: On a quarterly basis, the Data Center Management (DCM) team for each
datacenter is required to perform a review of the personnel with authorized access to their datacenter. The review consists
of reviewing reports from security showing personnel with current access to the datacenter. The DCM determines the
access changes to be made and communicates a request to security to have the changes performed. After the changes
have been made, the DCM team reviews reports verifying that the changes have been completed. The quarterly access
review is documented in a work ticket that includes the reports that were reviewed by the DCM team. These tickets are
reviewed as part of quality control / quality assurance process. The DC quarterly access review process is documented in
the DCS SOP.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 75

Cloud Implementation Guide for NERC Audits

The Azure DCM of a leased datacenter is responsible for conducting the same quarterly access review as they would for a
fully managed Azure datacenter. Instead of reviewing the access levels for the entire datacenter, the DCM would request
the access list for the Microsoft areas from the datacenter's security team. The DCM is responsible for ensuring that both
the landlord's access system and DCAT reflect the same data.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 102, 104 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 485 Covers NIST 800-53 PE-2
Datacenter Physical Standard Operating 13.4 6/28/2018 1-185 CIP-004-6 R4.2
Security SOP for Procedures for
Operations v13.4.docx Operations

R4 Part 4.3

CIP-004-6 Table R4 – Access Management Program

Part Applicable Systems Requirements Measures

4.3 High Impact BES Cyber Systems and For electronic access, verify at least once An example of evidence may
their associated: every 15 calendar months that all user include, but is not limited to,
1. EACMS; and accounts, user account groups, or user documentation of the review that
2. PACS role categories, and their specific, includes all of the following:
associated privileges are correct and are
1. A dated listing of all
Medium Impact BES Cyber Systems those that the Responsible Entity
accounts/account groups or roles
with External Routable Connectivity determines are necessary.
within the system;
and their associated:
1. EACMS; and 2. A summary description of
2. PACS privileges associated with each
group or role;
3. Accounts assigned to the group
or role; and
4. Dated evidence showing
verification of the privileges for
the group are authorized and
appropriate to the work function
performed by people assigned to
each account.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 76

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for reviewing user accounts, groups, and their access privileges every 15 months.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-2 Account Management: The service team's management identifies service team personnel who should
be given authorization to access the system and specifies the type of privilege each service team personnel should have
based on their role. Role-Based Access Control (RBAC) is used to identify and control the access privileges of each service
team personnel. Access privileges vary depending on the role a specified service team member will assume within the
service team. Access privileges are defined in the RAMWeb tool or Account Management Tool and enforced by Active
Directory. Accounts that have access to Microsoft Azure systems must be reviewed every 90 days by Microsoft Azure
group owners.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 102, 104 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R4 Part 4.4

CIP-004-6 Table R4 – Access Management Program

Part Applicable Systems Requirements Measures

4.4 High Impact BES Cyber Systems and their Verify at least once every 15 calendar An example of evidence may
associated: months that access to the designated include, but is not limited to, the
1. EACMS; and storage locations for BES Cyber System documentation of the review that
2. PACS Information, whether physical or includes all of the following:
electronic, are correct and are those that
1. A dated listing of authorizations
Medium Impact BES Cyber Systems the Responsible Entity determines are
for BES Cyber System information;
with External Routable Connectivity necessary for performing assigned work
and their associated: functions. 2. Any privileges associated with
1. EACMS; and the authorizations; and
2. PACS 3. Dated evidence showing a
verification of the authorizations
and any privileges were confirmed
correct and the minimum
necessary for performing assigned
work functions.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 77

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for reviewing storage access privileges every 15 months.

Cloud Provider Responsibility: Yes

By default, Azure personnel do not have access to customer storage accounts, which is controlled by Storage Account Keys
generated randomly when the storage account is created or later at customer’s request. Access to customer storage
accounts is not needed to operate Azure. All customer data in Azure Storage or SQL Database is encrypted by default and
this encryption cannot be disabled.

NIST 800-53 AC-2 Account Management: Accounts that have access to Microsoft Azure systems must be reviewed every
90 days by Azure group owners. Role-Based Access Control (RBAC) is used to identify and control the access privileges of
each Azure service team personnel. Access privileges vary depending on the role a specified team member has within the
service team. Access privileges are defined in the RAMWeb tool and enforced by Microsoft corporate Active Directory.

NIST 800-53 PE-2 Physical Access Authorizations: On a quarterly basis, the Data Center Management (DCM) team for each
datacenter is required to perform a review of the personnel with authorized access to their datacenter. The review consists
of reviewing reports from security showing personnel with current access to the datacenter. The DCM determines the
access changes to be made and communicates a request to security to have the changes performed. After the changes
have been made, the DCM team reviews reports verifying that the changes have been completed. The quarterly access
review is documented in a work ticket that includes the reports that were reviewed by the DCM team. These tickets are
reviewed as part of quality control / quality assurance process. The DC quarterly access review process is documented in
the DCS SOP.

The Azure DCM of a leased datacenter is responsible for conducting the same quarterly access review as they would for a
fully-managed Azure datacenter. Instead of reviewing the access levels for the entire datacenter, the DCM would request
the access list for the Microsoft areas from the datacenter's security team. The DCM is responsible for ensuring that both
the landlord's access system and DCAT reflect the same data.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 102, 104 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 485 Covers NIST 800-53 PE-2
Datacenter Physical Standard Operating 13.4 6/28/2018 1-185 CIP-004-6 R4.3
Security SOP for Procedures for
Operations v13.4.docx Operations

MICROSOFT CONFIDENTIAL – NDA REQUIRED 78

Cloud Implementation Guide for NERC Audits

R5 Supporting Evidence and Documentation

R5. Each Responsible Entity shall implement one or more documented access revocation program(s) that
collectively include each of the applicable requirement parts in CIP-004-6 Table R5 – Access Revocation.
[Violation Risk Factor: Medium] [Time Horizon: Same Day Operations and Operations Planning].
M5. Evidence must include each of the applicable documented programs that collectively include each of the
applicable requirement parts in CIP-004-6 Table R5 – Access Revocation and additional evidence to demonstrate
implementation as described in the Measures column of the table.

R5 Part 5.1

CIP-004-6 Table R5 – Access Revocation

Part Applicable Systems Requirements Measures

5.1 High Impact BES Cyber Systems A process to initiate removal of an An example of evidence may include,
and their associated: individual’s ability for unescorted but is not limited to, documentation of
1. EACMS; and physical access and Interactive Remote all of the following:
2. PACS Access upon a termination action, and
1. Dated workflow or sign-off form
complete the removals within 24 hours
verifying access removal associated
Medium Impact BES Cyber of the termination action (Removal of
with the termination action; and
Systems with External Routable the ability for access may be different
Connectivity and their than deletion, disabling, revocation, or 2. Logs or other demonstration
associated: removal of all access rights). showing such persons no longer have
1. EACMS; and access.
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for establishing a process to remove employee electronic access to Azure resources
following a termination action. For example, Registered Entity can deploy Active Directory Federation Services with Azure
Active Directory to enable users to authenticate using on-premises credentials and access resources in the cloud. If an
employee is terminated, his federated access to the Microsoft Azure Portal can be turned off simply by removing that
employee from the on-premises Active Directory.

Cloud Provider Responsibility: Yes

The process for creating and terminating user accounts is described on Microsoft Core Services Engineering (CSE) site
(internal link – confidential). FedRAMP requires that, upon termination of individual employment, access revocation take
place the same day. This requirement is consistent with CIP-004-6 R5.1.

NIST 800-53 PS-4 Personnel Termination: Microsoft HR ensures personnel termination is handled appropriately. On the
last day of employment, the employee is terminated from the HR system via a Termination Transaction ticket entered in
HeadTrax and approved by the HR Assistant or Business Administrator. Once the transaction has been keyed in and
approved, Microsoft Accounts and Security teams are notified and access to information systems is disabled. For
involuntary terminations an urgent request for access termination is submitted via email from HR and access is disabled
immediately. When an employee is terminated, the employee is removed from the Human Resources Information System
MICROSOFT CONFIDENTIAL – NDA REQUIRED 79
Cloud Implementation Guide for NERC Audits

(HRIS). When a service team user is marked as terminated in HRIS, this information propagates to Microsoft Active
Directory, which then automatically removes/revokes any authenticators/credentials associated with the individual. Upon
termination, building access badges are collected.

NIST 800-53 AC-2 Account Management: When a user leaves the company, notification of the leave is sent to their
respective manager and the Microsoft Azure group HR administrator. The HR administrator notifies Core Services
Engineering (CSE, formerly MSIT) and Global Security of the employees last working day. The HR administrator enters the
employee’s last day of work into the HR system HeadTrax to ensure accounts tied to their corporate credentials are
disabled on the employee’s last working day. As a result, user accounts get disabled on Microsoft Azure information
systems upon the employee’s last working day. Additionally, the access privileges tool RAMWeb is linked to HeadTrax,
and if users change organizations their access to resources provided as part of their RAMWeb membership is automatically
revoked depending on the policy specified in the associated RAMWeb project.

NIST 800-53 AC-2(3) Account Management | Disable Inactive Accounts: User accounts are automatically evaluated to
determine if they are actively being used by Microsoft users. The One Identity Life Cycle Management process is used to
disable any user accounts within Azure-managed domains (including Azure Infrastructure domain for Azure environment)
on a daily basis if there are no associated HR records (terminations). One Identity Life Cycle Management receives a daily
HR feed of employees, which it compares to the list of Azure-managed domains users. Any user accounts that do not have
a matching HR record, or have been flagged as inactive are then disabled by this process.

NIST 800-53 PE-2 Physical Access Authorizations: The physical security team and the Data Center Management (DCM)
team conduct a quarterly review of the access control list in order to remove/update individual access as necessary.
Additionally, the Datacenter Access Tool (DCAT) system performs real time comparisons of access authorization and
automatically removes access when access tickets expire naturally, and/or upon manual closure/termination of an access
ticket or the termination of a Microsoft employee or vendor via the Human Resources system HeadTrax. When access is
no longer required, it is the standard procedure for security officers at the datacenter or the DCM team to manually
request the termination of access. Terminations are handled immediately through a DCAT termination process.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 533-534 Covers NIST 800-53 PS-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 104 Covers NIST 800-53 AC-2
“ “ “ “ 113 Covers NIST 800-53 AC-2(3)
“ “ “ “ 486 Covers NIST 800-53 PE-2

MICROSOFT CONFIDENTIAL – NDA REQUIRED 80

Cloud Implementation Guide for NERC Audits

R5 Part 5.2

CIP-004-6 Table R5 – Access Revocation

Part Applicable Systems Requirements Measures

5.2 High Impact BES Cyber Systems For reassignments or transfers, An example of evidence may include,
and their associated: revoke the individual’s authorized but is not limited to, documentation
1. EACMS; and electronic access to individual of all of the following:
2. PACS accounts and authorized unescorted
1. Dated workflow or sign-off form
physical access that the Responsible
showing a review of logical and
Medium Impact BES Cyber Entity determines are not necessary
physical access; and
Systems with External Routable by the end of the next calendar day
Connectivity and their following the date that the 2. Logs or other demonstration
associated: Responsible Entity determines that showing such persons no longer have
1. EACMS; and the individual no longer requires access that the Responsible Entity
2. PACS retention of that access. determines is not necessary.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for establishing a process to revoke employee electronic access to Azure resources
following a reassignment or transfer. For example, Registered Entity can use Azure Active Directory to remove employee
access to Azure resources.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-2 Account Management: When a user is promoted or transferred to another group, user role and access
rights are automatically reviewed and revoked according to the access policy defined with the RAMWeb tool for accessing
that particular component. The user profile is changed after proper approvals and authorization from the respective group
owners. Since RAMWeb is linked to the HR system HeadTrax, if users change organizations their access to resources
provided as part of their RAMWeb membership is automatically revoked depending on the policy specified in the
associated RAMWeb project. Furthermore, the RAMWeb tool will automatically disable access depending on the rules
configured for the project. The user is required to resubmit a request for access when that individual’s access is close to
expiring.

NIST 800-53 PE-2 Physical Access Authorizations: The physical security team and the Data Center Management (DCM)
team conduct a quarterly review of the access control list in order to remove/update individual access as necessary.
Additionally, the Datacenter Access Tool (DCAT) system performs real time comparisons of access authorization and
automatically removes access when access tickets expire naturally, and/or upon manual closure/termination of an access
ticket or the termination of a Microsoft employee or vendor via the Human Resources system HeadTrax. When access is
no longer required, it is the standard procedure for security officers at the datacenter or the DCM team to manually
request the termination of access. Terminations are handled immediately through a DCAT termination process.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 81

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 106 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 486 Covers NIST 800-53 PE-2

R5 Part 5.3

CIP-004-6 Table R5 – Access Revocation

Part Applicable Systems Requirements Measures

5.3 High Impact BES Cyber Systems For termination actions, revoke the An example of evidence may include,
and their associated: individual’s access to the designated but is not limited to, workflow or sign-
1. EACMS; and storage locations for BES Cyber System off form verifying access removal to
2. PACS Information, whether physical or designated physical areas or cyber
electronic (unless already revoked systems containing BES Cyber System
Medium Impact BES Cyber according to Requirement R5.1), by the Information associated with the
Systems with External Routable end of the next calendar day following terminations and dated within the
Connectivity and their associated: the effective date of the termination next calendar day of the termination
1. EACMS; and action. action.
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for establishing a process to revoke employee electronic access to Azure resources
following a termination action. For example, Registered Entity can deploy Active Directory Federation Services with Azure
Active Directory to enable users to authenticate using on-premises credentials and access resources in the cloud. If an
employee is terminated, his federated access to the Microsoft Azure Portal can be turned off simply by removing that
employee from the on-premises Active Directory. Moreover, Registered Entity can use Azure Active Directory to remove
employee access to Azure resources, including storage accounts. Registered Entity is responsible for timely termination of
account credentials when employees, contractors, or consultants leave the organization.

Cloud Provider Responsibility: Yes

Azure personnel do not have access to customer storage accounts, which is controlled by Storage Account Keys generated
randomly when the storage account is created or later at customer’s request. Access to customer storage accounts is not
needed to operate Azure. All customer data in Azure Storage or SQL Database is encrypted by default and this encryption
cannot be disabled.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 82

Cloud Implementation Guide for NERC Audits

NIST 800-53 PS-4 Personnel Termination: On the last day of employment, the employee is terminated from the HR system
via a Termination Transaction ticket entered in HeadTrax and approved by the HR Assistant or Business Administrator.
Once the transaction has been keyed in and approved, Microsoft Accounts and Security teams are notified and access to
information systems is disabled. For involuntary terminations an urgent request for access termination is submitted via
email from HR and access is disabled immediately. When an employee is terminated, the employee is removed from the
Human Resources Information System (HRIS). When a service team user is marked as terminated in HRIS, this information
propagates to Microsoft Active Directory, which then automatically removes/revokes any authenticators/credentials
associated with the individual. Upon termination, building access badges are collected. This process is described and
already covered under CIP-004-6 R5.1.

NIST 800-53 AC-2 Account Management: Accounts that have access to Microsoft Azure systems must be reviewed every
90 days by Microsoft Azure group owners. Additionally, when a user is promoted or transferred to another group, user
role and access rights are automatically reviewed and revoked according to the access policy defined with the RAMWeb
tool. The user profile is changed after proper approvals and authorization from the respective group owners. Since
RAMWeb is linked to the corporate Human Resources (HR) tracking tool Headtrax, if users change organizations, their
access to resources provided as part of their RAMWeb membership is automatically revoked depending on the policy
specified in the associated RAMWeb project. Furthermore, the RAMWeb tool will automatically terminate access
depending on the rules configured for the project. The user is required to resubmit a request for access when that
individual’s access is close to expiring.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 533-534 Covers NIST 800-53 PS-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 104 Covers NIST 800-53 AC-2

R5 Part 5.4

CIP-004-6 Table R5 – Access Revocation

Part Applicable Systems Requirements Measures

5.4 High Impact BES Cyber Systems and For termination actions, revoke the An example of evidence may include,
their associated: individual’s non-shared user but is not limited to, workflow or sign-
• EACMS accounts (unless already revoked off form showing access removal for
according to Parts 5.1 or 5.3) within any individual BES Cyber Assets and
30 calendar days of the effective software applications as determined
date of the termination action. necessary to completing the revocation
of access and dated within thirty
calendar days of the termination
actions.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 83

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for establishing a process to revoke employee’s non-shared user accounts following a
termination action. For example, Registered Entity can use Microsoft Active Directory to manage their user accounts,
including access revocation. Registered Entity is responsible for timely termination of account credentials when
employees, contractors, or consultants leave the organization.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-2 Account Management: When a user leaves the company, notification of the leave is sent to their
respective manager and the Microsoft Azure group HR administrator. The HR administrator notifies Core Services
Engineering (CSE, formerly MSIT) and Global Security of the employees last working day. The HR administrator enters the
employee’s last day of work into the HR system HeadTrax to ensure accounts tied to their corporate credentials are
disabled on the employee’s last working day. As a result, user accounts get disabled on Microsoft Azure information
systems upon the employee’s last working day. Additionally, the access privileges tool RAMWeb is linked to HeadTrax,
and if users change organizations their access to resources provided as part of their RAMWeb membership is automatically
revoked depending on the policy specified in the associated RAMWeb project.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 104 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 84

Cloud Implementation Guide for NERC Audits

R5 Part 5.5

CIP-004-6 Table R5 – Access Revocation

Part Applicable Systems Requirements Measures

5.5 High Impact BES Cyber Systems For termination actions, change Examples of evidence may include,
and their associated: passwords for shared account(s) but are not limited to:
• EACMS known to the user within 30 calendar
1. Workflow or sign-off form showing
days of the termination action. For
password reset within 30 calendar
reassignments or transfers, change
days of the termination;
passwords for shared account(s)
known to the user within 30 calendar 2. Workflow or sign-off form showing
days following the date that the password reset within 30 calendar
Responsible Entity determines that the days of the reassignments or
individual no longer requires retention transfers; or
of that access.
3. Documentation of the extenuating
If the Responsible Entity determines operating circumstance and workflow
and documents that extenuating or sign-off form showing password
operating circumstances require a reset within 10 calendar days
longer time period, change the following the end of the operating
password(s) within 10 calendar days circumstance.
following the end of the operating
circumstances.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for terminating or changing shared or group account credentials within 30 days of a
member leaving the group.

Cloud Provider Responsibility: Yes

FedRAMP does not prescribe a time horizon for changing passwords for shared accounts. In NIST 800-53 AC-2(10) Control
Enhancement, FedRAMP prescribes that shared/group account credentials should be terminated when members leave
the group. Microsoft Azure implementation of the corresponding NIST control specifies that shared account credentials
are required to be rotated whenever an employee leaves the group. Microsoft can furnish evidence upon request that
time horizon involved with credential rotation for shared accounts is less than 30 days when an employee leaves that
group.

NIST 800-53 AC-2(10) Account Management | Shared / Group Account Credential Termination: Microsoft Azure only
allows the use of shared or group accounts when those accounts are required for a clearly-defined administrative purpose
that cannot be fulfilled with individual accounts. The credentials for these accounts must be stored in one of the approved
Secret Stores, which tracks and monitors access to secrets. Account owners are required to rotate shared account
credentials at least every 70 days. Additionally, account owners are required to rotate shared account credentials
whenever an employee leaves the group.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 85

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 119-120 Covers NIST 800-53 AC-
Moderate System Moderate System 2(10)
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 86

Cloud Implementation Guide for NERC Audits

CIP-005-5 – Cyber Security – Electronic Security Perimeter(s)

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented processes that collectively include each of
the applicable requirement parts in CIP-005-5 Table R1 – Electronic Security Perimeter. [Violation Risk Factor:
Medium] [Time Horizon: Operations Planning and Same Day Operations].
M1. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-005-5 Table R1 – Electronic Security Perimeter and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R1 Part 1.1

CIP-005-5 Table R1 – Electronic Security Perimeter

Part Applicable Systems Requirements Measures

1.1 High Impact BES Cyber Systems and All applicable Cyber Assets An example of evidence may include, but is
their associated: connected to a network via a not limited to, a list of all ESPs with all
• PCA routable protocol shall reside within uniquely identifiable applicable Cyber
a defined ESP. Assets connected via a routable protocol
Medium Impact BES Cyber Systems
within each ESP.
and their associated:
• PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for segmenting BES Cyber Systems from other systems of differing trust levels. The logical
isolation of customer infrastructure in Azure or Azure Government is fundamental to maintaining security. The
overarching principle for a virtualized solution is to allow only connections and communications that are necessary for
that virtualized solution to operate, blocking all other ports and connections by default. Virtual Network (VNET) in Azure
and Azure Government helps ensure that each customer’s private network traffic is logically isolated from traffic belonging
to other customers. A customer subscription can contain multiple logically isolated private networks, and include firewall,
load-balancing, and network address translation. These sub-divided networks generally fall into one of the two categories:

• Deployment network: Each deployment can be isolated from other deployments at the network level. Multiple Virtual
Machines (VMs) within a deployment can communicate with each other through private IP addresses.
• Virtual network: Each virtual network is isolated from other virtual networks. Multiple deployments inside the same
subscription can be placed on the same virtual network, and then communicate with each other through private IP
addresses.

Registered Entity is wholly responsible for configuring their VNETs and segmenting applications deployed inside those
networks. For more information, see section titled Networking Isolation in “NERC CIP Standards and Cloud Computing”.
Specifically, Registered Entity is responsible for:

• Monitoring and controlling communications at and within the boundaries of the customer-deployed system.
• Implementing subnetworks for customer-deployed resources to logically separate publicly accessible resources from

MICROSOFT CONFIDENTIAL – NDA REQUIRED 87

Cloud Implementation Guide for NERC Audits

internal resources.
• Restricting connections to external networks or systems through managed interfaces, consisting of boundary protection
devices arranged in accordance with the customer’s security architecture.

Cloud Provider Responsibility: No

As stated in the corresponding standard CIP-005-5, section titled Guidelines and Technical Basis, Page 15-16, CIP-005-5 R1
requires segmenting BES Cyber Systems from other systems of differing trust levels by requiring controlled Electronic
Access Points between the different trust zones. All applicable BES Cyber Systems that are connected to a network via a
routable protocol must have a defined Electronic Security Perimeter (ESP). If there is routable connectivity across the ESP
into any Cyber Asset, then an Electronic Access Point (EAP) must control traffic into and out of the ESP.

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which ports and protocols need to be enabled
for a properly functioning BES Cyber Asset. Neither Azure nor Azure Government constitutes a BES Cyber System or BES
Cyber Asset. Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is
meant primarily to demonstrate controls that Microsoft has in place across Azure for secure segmentation of network
environments.

NIST 800-53 SC-7 Boundary Protection: Microsoft Azure implements boundary protection using controlled devices at the
network boundary and at key points within the Microsoft Azure infrastructure. The overarching principle within Microsoft
Azure is to allow only connection and communication that is necessary for systems to operate, blocking all other ports,
protocols and connections by default. Azure employs a defense in depth strategy for boundary protection, including
secure segmentation of network environments through several methods including VLAN segmentation, ACL restrictions,
and encrypted communications for remote connectivity (SSL VPN and Remote Desktop Gateway access) to the
environment. Furthermore, techniques like control plane policing security are used to isolate services. The key boundaries
included as part of Azure’s Infrastructure include the Global Infrastructure LAN used to support infrastructure supporting
services and the external boundary of the RD Gateway and SSL VPN boundary used to support remote access to the
environment.

The combination of the following components acts as Azure Infrastructure’s boundary protection:

• Edge Routers
• Access Routers
• Load Balancers
• Layer 2 Aggregation
• TOR
• ACL Restrictions
• Monitoring

The only publicly accessible components of Microsoft Azure are the load balancers and the public-facing server roles. All
non-publicly accessible Azure components connect to the load balancers via physically separate network interfaces on
subnets that are logically separated from internal subnets.

Azure connects to external networks or information systems only through Azure Networking’s managed networks and
edge routers. The network interfaces provide boundary protection at the edge router network level and are arranged in
accordance with organizational security architecture. Additional measures in place to help protect Azure information
systems from malicious activities include:

• Software load balancers

• Non-routable IP addressing
MICROSOFT CONFIDENTIAL – NDA REQUIRED 88
Cloud Implementation Guide for NERC Audits

• Packet filtering
• Host-based firewalls
• VLAN isolation
• Jump boxes

All traffic at the boundary is restricted to authorized connections. Public access to the system is strictly prohibited.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 619-622 Covers NIST 800-53 SC-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.2

CIP-005-5 Table R1 – Electronic Security Perimeter

Part Applicable Systems Requirements Measures

1.2 High Impact BES Cyber Systems with All External Routable Connectivity An example of evidence may include, but is
External Routable Connectivity and must be through an identified not limited to, network diagrams showing
their associated: Electronic Access Point (EAP). all external routable communication paths
• PCA and the identified EAPs.
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
• PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is accountable for maintaining a complete inventory of its information assets, including networking
infrastructure diagrams that show external routable communication paths. Customers should review Azure
documentation on network boundary security and network security best practices.

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which ports and protocols need to be enabled
for a properly functioning BES Cyber Asset. Neither Azure nor Azure Government constitutes a BES Cyber System or BES
Cyber Asset. Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is
meant primarily to demonstrate controls that Microsoft has in place across Azure for secure segmentation of network
environments.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 89

Cloud Implementation Guide for NERC Audits

For network diagram, see Figure 9-16: Microsoft Azure Network Architecture on Page 51 in the FedRAMP Moderate
System Security Plan. Figure 10-1: Production Network Access Mechanism (Page 55) illustrates the access mechanism to
the core production network where Azure resides. For different layers of network isolation provided to Azure customers,
see Isolation in the Azure cloud.

NIST 800-53 SC-7 Boundary Protection: The only publicly-accessible components of Microsoft Azure are the load balancers
and the public-facing server roles. All non-publicly-accessible Azure components connect to the load balancers via
physically-separate network interfaces on subnets that are logically separated from internal subnets.

Microsoft Azure connects to external networks or information systems only through Azure Networking managed networks
and edge routers. The network interfaces provide boundary protection at the edge router network level and are arranged
in accordance with organizational security architecture.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 621-622 Covers NIST 800-53 SC-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.3

CIP-005-5 Table R1 – Electronic Security Perimeter

Part Applicable Systems Requirements Measures

1.3 Electronic Access Points for High Require inbound and outbound An example of evidence may include, but is
Impact BES Cyber Systems access permissions, including the not limited to, a list of rules (firewall, access
reason for granting access, and deny control lists, etc.) that demonstrate that
Electronic Access Points for Medium
all other access by default. only permitted access is allowed and that
Impact BES Cyber Systems
each access rule has a documented reason.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for maintaining configuration documents on boundary protection showing the current
state of all ports and protocols. Customers should review Azure network security documentation.

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which ports and protocols need to be enabled
for a properly functioning BES Cyber Asset. Neither Azure nor Azure Government constitutes a BES Cyber System or BES
Cyber Asset. Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is
meant primarily to demonstrate controls that Microsoft has in place across Azure for network boundary protection.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 90
Cloud Implementation Guide for NERC Audits

NIST 800-53 SC-7(5) Boundary Protection | Deny by Default / Allow by Exception: The over-arching principle of Microsoft
Azure network security is deny-by-default, which means allowing only connection and communication that is necessary
for systems to operate, blocking all other ports, protocols, and connections by default. Azure only allows connections and
communication that are necessary to operate the system. Connections are managed at the system boundary using Azure
Networking boundary protection devices. Connections within the boundary are managed using:

• IP Filtering
• VFP Filtering (for virtual machines)
• Host-based firewalls
• Guest firewalls (for virtual machines)

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 626 Covers NIST 800-53 SC-7(5)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.4

CIP-005-5 Table R1 – Electronic Security Perimeter

Part Applicable Systems Requirements Measures

1.4 High Impact BES Cyber Systems with Where technically feasible, perform An example of evidence may include, but
Dial-up Connectivity and their authentication when establishing is not limited to, a documented process
associated: Dial-up Connectivity with applicable that describes how the Responsible Entity
• PCA Cyber Assets. is providing authenticated access through
each dial-up connection.
Medium Impact BES Cyber Systems
with Dial-up Connectivity and their
associated:
• PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for maintaining documentation covering authentication and authorization for all remote
access solutions, including dial-up connectivity to their internal systems.

Cloud Provider Responsibility: No

Not applicable because dial-up access is not provided through Microsoft Azure.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 91

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
N/A N/A N/A N/A N/A N/A

R1 Part 1.5

CIP-005-5 Table R1 – Electronic Security Perimeter

Part Applicable Systems Requirements Measures

1.5 Electronic Access Points for High Have one or more methods for An example of evidence may include, but
Impact BES Cyber Systems detecting known or suspected is not limited to, documentation that
malicious communications for both malicious communications detection
Electronic Access Points for Medium
inbound and outbound methods (e.g. intrusion detection system,
Impact BES Cyber Systems at Control
communications. application layer firewall, etc.) are
Centers
implemented.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for maintaining documentation on Intrusion Detection System / Intrusion Protection
System (IDS/IPS), application firewall, and antimalware protection implemented for assets deployed in the cloud.
Customers can leverage Azure Advanced Threat Protection and Azure Security Center for help with preventing, detecting,
and responding to threats with visibility and control over the security of all provisioned Azure resources. Using Microsoft
global threat intelligence, security-related events from across customer Azure deployments are automatically collected
and analyzed to identify actual threats and reduce false alarms. The resulting alerts offer insights into the attack and
suggest ways to remediate issues. Customers should review Introduction to Azure Security Center, overview of Security
Management in Azure, and documentation on Antimalware for Azure cloud services and virtual machines.

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System and what kind of inbound or outbound traffic
directed towards customer BES Cyber System indicates malicious communication. Neither Azure nor Azure Government
constitutes a BES Cyber System or BES Cyber Asset. Microsoft monitors inbound and outbound communication at the
platform level, not at individual customer application level. Registered Entity is wholly responsible for complying with
CIP-005-5. The information provided below is meant primarily to demonstrate controls that Microsoft has in place across
Azure for host intrusion detection and protection.

NIST 800-53 SC-7(12) Boundary Protection | Host-Based Protection: Microsoft Azure implements the following host-
based boundary protection mechanisms:
• IP Filtering
• VFP Filtering (for virtual machines)
• Host-based firewalls
MICROSOFT CONFIDENTIAL – NDA REQUIRED 92
Cloud Implementation Guide for NERC Audits

• Guest firewalls (for virtual machines)

• Multi-Factor Authentication (MFA)

The servers within MFA are protected through NAT mechanisms and access controls are suitably established by Azure’s
Infrastructure at the network layer. The access to the MFA production infrastructure is restricted to minimal number of
ports, protocols and services required for the service. MFA also scans and monitors the servers periodically for any
unauthorized / intrusive activities and takes action to remediate the underlying immediately with the help of 24x7 on-call
operations team.

NIST 800-53 SI-4(4) Information System Monitoring | Inbound and Outbound Communication Traffic: Microsoft Azure
inbound and outbound communications are monitored continually using centralized monitoring, correlation, and analysis
systems that manage the large amount of information generated by devices within the environment. Geneva Monitoring
provides automated logging and alerting capabilities by utilizing Monitoring Agents (MAs) throughout the system. The
Azure Alarm and Incident Management Service (AIMS) is used to generate alerts for service teams.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 629 Covers NIST 800-53 SC-
Moderate System Moderate System 7(12)
Security Plan v3.05.pdf Security Plan
“ “ “ “ 685 Covers NIST 800-53 SI-4(4)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 93

Cloud Implementation Guide for NERC Audits

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity allowing Interactive Remote Access to BES Cyber Systems shall implement one or more
documented processes that collectively include the applicable requirement parts, where technically feasible, in
CIP-005-5 Table R2 – Interactive Remote Access Management. [Violation Risk Factor: Medium] [Time Horizon:
Operations Planning and Same Day Operations].
M2. Evidence must include the documented processes that collectively address each of the applicable requirement
parts in CIP-005-5 Table R2 – Interactive Remote Access Management and additional evidence to demonstrate
implementation as described in the Measures column of the table.

R2 Part 2.1

CIP-005-5 Table R2 – Interactive Remote Access Management

Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems Utilize an Intermediate System such Examples of evidence may include, but are not
and their associated: that the Cyber Asset initiating limited to, network diagrams or architecture
• PCA Interactive Remote Access does not documents.
directly access an applicable Cyber
Medium Impact BES Cyber
Asset.
Systems with External Routable
Connectivity and their
associated:
• PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for documenting remote access requirements to customer-deployed resources, including
usage restrictions, configuration and connection requirements, and implementation guidance for all remote access types.
Registered Entity is responsible for deploying an intermediate system to prevent direct remote access to applicable BES
Cyber Assets. For example, customers can use Azure Application Gateway to build a scalable and highly available front-
end in Azure that supports web application firewall, URL routing, multiple site hosting, multi-tenant back ends, etc.

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which incoming traffic is directed towards
customer BES Cyber Assets. Neither Azure nor Azure Government constitutes a BES Cyber System or BES Cyber Asset.
Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is meant primarily
to demonstrate controls that Microsoft has in place across Azure for secure remote access to production systems that is
provided to Microsoft engineers for system maintenance and troubleshooting. These controls are unrelated to Interactive
Remote Access to customer BES Cyber Assets and corresponding Intermediate Systems, which are completely outside
Microsoft control.

NIST 800-53 AC-17 Remote Access: Microsoft authorizes remote access for Azure service team users. Before service team
personnel can connect to Azure remotely, they must first be approved for remote access by an authorized manager. This
process is automatically enforced through RAMWeb and Account Management Tool, as described under CIP-004-6 R4.1.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 94

Cloud Implementation Guide for NERC Audits

Microsoft internal user connections originate in the Corporate Network (CorpNet) passing via the CorpNet firewall through
Azure-managed load balancers. Authorized Azure personnel utilize Microsoft-issued information systems (Secure Access
Workstation, SAW) and connect remotely to the Azure cluster from CorpNet. Users are identified via two-factor
authentication based on a unique Active Directory (AD) identifier and password from the Corporate domain in
combination with a smart card. SAW use and operation policy is available (internal link). SAWs are security devices that
provide users with privileged or elevated access to Azure production systems for platform troubleshooting and
maintenance. A SAW is designed to protect users from credential theft/misuse and malware attacks. SAWs are monitored
by Microsoft.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 153-154 Covers NIST 800-53 AC-17
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.2

CIP-005-5 Table R2 – Interactive Remote Access Management

Part Applicable Systems Requirements Measures

2.2 High Impact BES Cyber Systems For all Interactive Remote Access An example of evidence may include, but is not
and their associated: sessions, utilize encryption that limited to, architecture documents detailing
• PCA terminates at an Intermediate where encryption initiates and terminates.
System.
Medium Impact BES Cyber
Systems with External Routable
Connectivity and their
associated:
• PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for enabling encryption for traffic between end users and Azure resources such as Virtual
Machines or storage accounts, configuring HTTPS endpoints for Azure instances, using Internet Protocol Security (IPsec)
to encrypt traffic between its corporate VPN gateway and Azure, etc. Azure provides strong support for data encryption
both in transit and at rest. Customers should review Azure data security and encryption best practices. For example,
customers can use Azure Application Gateway, which supports SSL termination at the gateway, after which traffic typically
flows unencrypted to backend servers. However, Application Gateway also supports end-to-end SSL which may be
preferable by some customers due to security and compliance requirements.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 95

Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which incoming traffic is directed towards
customer BES Cyber Assets. Neither Azure nor Azure Government constitutes a BES Cyber System or BES Cyber Asset.
Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is meant primarily
to demonstrate controls that Microsoft has in place across Azure for encrypted remote access to production systems that
is provided to Microsoft engineers for system maintenance and troubleshooting. These controls are unrelated to
Interactive Remote Access to customer BES Cyber Assets and corresponding Intermediate Systems, which are completely
outside Microsoft control.

NIST 800-53 AC-17(2) Remote Access | Protection of Confidentiality / Integrity Using Encryption: For all asset types,
Microsoft Azure uses cryptographic controls to protect the confidentiality and integrity of sensitive data while in transit
or at rest. To ensure confidentiality, Azure uses both symmetric and asymmetric keys for encrypting sensitive data to
prevent access from unauthorized parties. To ensure integrity, Azure uses asymmetric keys to protect unauthorized
modification to sensitive data during transmission across components.

Azure Remote Desktop Gateways and SSL VPN services are configured to use FIPS 140-02 validated TLS 1.2 encryption for
remote access. Encryption is required for all remote access connections. PKI certificates are utilized within Azure on the
internal RD gateways and are obtained through the Azure Infrastructure PKI and SSL certificates utilized by remote access
solutions.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 156 Covers NIST 800-53 AC-
Moderate System Moderate System 17(2)
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 96

Cloud Implementation Guide for NERC Audits

R2 Part 2.3

CIP-005-5 Table R2 – Interactive Remote Access Management

Part Applicable Systems Requirements Measures

2.3 High Impact BES Cyber Systems Require multi-factor authentication An example of evidence may include, but is not
and their associated: for all Interactive Remote Access limited to, architecture documents detailing
• PCA sessions. the authentication factors used.
Medium Impact BES Cyber Examples of authenticators may include, but
Systems with External Routable are not limited to,
Connectivity and their • Something the individual knows such
associated: as passwords or PINs. This does not
• PCA include User ID;
• Something the individual has such as
tokens, digital certificates, or smart
cards; or
• Something the individual is such as
fingerprints, iris scans, or other
biometric characteristics.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for establishing electronic access to its applications and data hosted in Azure based on
two-factor authentication for end users. Registered Entity can use Azure Multi-Factor Authentication to help safeguard
access to data and applications while meeting user demand for a simple sign-on process. It delivers strong authentication
via a range of easy verification options—phone call, text message, or mobile app notification—allowing users to choose
the method they prefer. Customers use multi-factor authentication to protect access to sensitive information and to help
protect their organization from malicious attacks.

Cloud Provider Responsibility: No

Microsoft does not inspect, approve, or monitor customer applications deployed in Azure. Microsoft does not know which
Azure resources provisioned by customers constitute a BES Cyber System, or which incoming traffic is directed towards
customer BES Cyber Assets. Neither Azure nor Azure Government constitutes a BES Cyber System or BES Cyber Asset.
Registered Entity is wholly responsible for complying with CIP-005-5. The information provided below is meant primarily
to demonstrate controls that Microsoft has in place across Azure for Multi-Factor Authentication (MFA) involving remote
access to production systems that is provided to Microsoft engineers for system maintenance and troubleshooting. These
controls are unrelated to MFA for Interactive Remote Access to customer BES Cyber Assets, which is completely outside
Microsoft control.

NIST 800-53 AC-17 Remote Access: Microsoft internal user connections originate in the Corporate Network (CorpNet)
passing via the CorpNet firewall through Azure-managed load balancers. Authorized Azure personnel utilize Microsoft-
issued information systems (Secure Access Workstation, SAW) and connect remotely to the Azure cluster from CorpNet.
Users are identified via two-factor authentication based on a unique Active Directory (AD) identifier and password from
the Corporate domain in combination with a smart card. SAWs are security devices that provide users with privileged or
elevated access to Azure production systems for platform troubleshooting and maintenance. A SAW is designed to protect
users from credential theft/misuse and malware attacks. SAWs are monitored by Microsoft.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 97

Cloud Implementation Guide for NERC Audits

NIST 800-53 IA-2 Identification and Authentication (Organizational Users): Microsoft Azure personnel accessing the Azure
environment are uniquely identified by their Microsoft corporate Active Directory username and authenticated using
eAuth Level 4 and FIPS 140-2 compliant Gemalto smart cards or approved eAuth Level 4 and FIPS 140-2 compliant Trusted
Platform Modules (TPM). Active Directory strictly enforces unique identifiers.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 153-154 Covers NIST 800-53 AC-17
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 365 Covers NIST 800-53 IA-2

MICROSOFT CONFIDENTIAL – NDA REQUIRED 98

Cloud Implementation Guide for NERC Audits

CIP-006-6 – Cyber Security – Physical Security of BES Cyber Systems

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented physical security plan(s) that collectively
include all of the applicable requirement parts in CIP-006-6 Table R1 – Physical Security Plan. [Violation Risk
Factor: Medium] [Time Horizon: Long Term Planning and Same Day Operations].
M1. Evidence must include each of the documented physical security plans that collectively include all of the
applicable requirement parts in CIP-006-6 Table R1 – Physical Security Plan and additional evidence to
demonstrate implementation of the plan or plans as described in the Measures column of the table.

R1 Part 1.1

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.1 Medium Impact BES Cyber Systems Define operational or procedural An example of evidence may include, but is
without External Routable controls to restrict physical access. not limited to, documentation that
Connectivity operational or procedural controls exist.
Physical Access Control Systems
(PACS) associated with:
• High Impact BES Cyber
Systems, or
• Medium Impact BES Cyber
Systems with External
Routable Connectivity

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-3 Physical Access Control: Microsoft Azure enforces physical access authorizations for all physical access
points to Azure datacenters. The exteriors of the datacenter buildings are non-descript and do not advertise that they are
Microsoft datacenters. Depending on the design of a datacenter, physical access authorizations may begin at a controlled
perimeter gate or secured facility door that would require either access badge authorization or security officer
authorization.

Main access to Azure datacenter facilities is restricted to a single point of entry that is manned 24x7 by security personnel.
Emergency exits are alarmed and under video surveillance. Electronic access control devices are installed on doors
separating the reception area from the facilities’ interior to restrict access to approved personnel only. Azure datacenters
have a security operations desk located in the reception area and in line of sight of the single entry point. The datacenter
lobbies have man-trap portal devices that require access card and biometric hand geometry or fingerprint authentication
to pass beyond the lobby. Areas within Microsoft datacenters that contain critical systems (e.g., colocations, critical
environments, Main Distribution Frame MDF rooms, etc.) are further restricted through various security mechanisms such
as electronic access control, biometric devices, and anti-pass back controls. Additionally, doors are alarmed and under
MICROSOFT CONFIDENTIAL – NDA REQUIRED 99
Cloud Implementation Guide for NERC Audits

video surveillance.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 488 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Datacenter Physical Standard Operating 13.4 6/28/2018 1-185 CIP-006-6 R1.1
Security SOP for Procedures for
Operations v13.4.docx Operations

R1 Part 1.2

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.2 Medium Impact BES Cyber Systems Utilize at least one physical access An example of evidence may include, but is
with External Routable Connectivity control to allow unescorted physical not limited to, language in the physical
and their associated: access into each applicable Physical security plan that describes each Physical
1. EACMS; and Security Perimeter to only those Security Perimeter and how unescorted
2. PCA individuals who have authorized physical access is controlled by one or more
unescorted physical access. different methods and proof that
unescorted physical access is restricted to
only authorized individuals, such as a list of
authorized individuals accompanied by
access logs.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-3 Physical Access Control: Access authorizations at Azure datacenters are managed through the
Datacenter Access Tool (DCAT). DCAT contains the authorized access lists of personnel who have been approved by the
Datacenter Management (DCM) team. Access to areas within the datacenter is granted based on the least privilege
principle. Before a person arrives at a datacenter, they must have a DCAT request approved by the DCM team. The DCM
team reviews the request for a valid business justification and for appropriate access levels. Upon arriving at the
datacenter, the individual on the request must have their identification verified by the Control Room Supervisor against a
Microsoft identification badge or government issued identification card or document.

Azure datacenters (leased and fully-managed) utilize physical access devices such as metal detectors, perimeter gates,

MICROSOFT CONFIDENTIAL – NDA REQUIRED 100

Cloud Implementation Guide for NERC Audits

electronic access badge readers, biometric readers, man-traps/portals, anti-tailgate devices (in leased datacenters), and
anti-pass back controls, as well as security officers to control access to datacenters. As an additional security measure for
leased datacenters, Azure has required that anti-tailgating alarms be deployed at the doors to Microsoft colocation rooms.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 488 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.3

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.3 High Impact BES Cyber Systems and Where technically feasible, utilize An example of evidence may include, but is
their associated: two or more different physical not limited to, language in the physical
1. EACMS; and access controls (this does not security plan that describes the Physical
2. PCA require two completely independent Security Perimeters and how unescorted
physical access control systems) to physical access is controlled by two or more
collectively allow unescorted different methods and proof that
physical access into Physical Security unescorted physical access is restricted to
Perimeters to only those individuals only authorized individuals, such as a list of
who have authorized unescorted authorized individuals accompanied by
physical access. access logs.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-3 Physical Access Control: Access authorizations at Azure datacenters are managed through the
Datacenter Access Tool (DCAT). DCAT contains the authorized access lists of personnel who have been approved by the
Datacenter Management (DCM) team. Access to areas within the datacenter is granted based on the least privilege
principle. Before a person arrives at a datacenter, they must have a DCAT request approved by the DCM team. The DCM
team reviews the request for a valid business justification and for appropriate access levels. Upon arriving at the
datacenter, the individual on the request must have their identification verified by the Control Room Supervisor against a
Microsoft identification badge or government issued identification card or document.

Azure datacenters (leased and fully-managed) utilize physical access devices such as metal detectors, perimeter gates,
electronic access badge readers, biometric readers, man-traps/portals, anti-tailgate devices (in leased datacenters), and

MICROSOFT CONFIDENTIAL – NDA REQUIRED 101

Cloud Implementation Guide for NERC Audits

anti-pass back controls, as well as security officers to control access to datacenters. As an additional security measure for
leased datacenters, Azure has required that anti-tailgating alarms be deployed at the doors to Microsoft colocation rooms.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 488 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.4

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.4 High Impact BES Cyber Systems and Monitor for unauthorized access An example of evidence may include, but is
their associated: through a physical access point into not limited to, documentation of controls
1. EACMS; and a Physical Security Perimeter. that monitor for unauthorized access
2. PCA through a physical access point into a
Physical Security Perimeter.
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS; and
2. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-6 Monitoring Physical Access: Physical access is monitored by implementing security devices and processes
at the datacenters. Examples include 24x7 electronic monitoring of access control, alarm and video systems, as well as
24x7 on-site security patrols of the facility and grounds. A Control Room Supervisor is located in the Secure Operations
Center (SOC) at all times to provide monitoring of physical access in the datacenter. The Control Room Supervisor monitors
live camera feeds within the datacenter as well as the alarm monitoring system reports from all physical security access
devices within the datacenter. Physical access is reported in the alarm monitoring system as approved or failed. Failed
access results in an alarm status that requires action by the Control Room Supervisor. The Control Room Supervisor can
dispatch a responder for further investigation if needed. The physical access logs in the alarm monitoring system are
reviewed continuously, but are also available in log files for subsequent investigative review.

CCTV is employed to monitor physical access to the datacenter and the information system. The CCTV is linked to the
building alarm monitoring system to provide physical access monitoring of alarm points. Cameras are positioned to
MICROSOFT CONFIDENTIAL – NDA REQUIRED 102
Cloud Implementation Guide for NERC Audits

monitor perimeter doors, facility entrances and exits, all colocation rows and aisles, all racks, caged areas, high-security
areas, shipping and receiving, facility external areas such as parking lots and other areas of the facility.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 494 Covers NIST 800-53 PE-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.5

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.5 High Impact BES Cyber Systems and Issue an alarm or alert in response to An example of evidence may include, but is
their associated: detected unauthorized access not limited to, language in the physical
1. EACMS; and through a physical access point into security plan that describes the issuance of
2. PCA a Physical Security Perimeter to the an alarm or alert in response to
personnel identified in the BES Cyber unauthorized access through a physical
Medium Impact BES Cyber Systems
Security Incident response plan access control into a Physical Security
with External Routable Connectivity
within 15 minutes of detection. Perimeter and additional evidence that the
and their associated:
alarm or alert was issued and
1. EACMS; and
communicated as identified in the BES
2. PCA
Cyber Security Incident Response Plan, such
as manual or electronic alarm or alert logs,
cell phone or pager logs, or other evidence
that documents that the alarm or alert was
generated and communicated.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-6(1) Monitoring Physical Access | Intrusion Alarms / Surveillance Equipment: In addition to the 24x7 onsite
security, Azure datacenters (leased and fully-managed) also utilize alarm monitoring systems. This provides real-time
alarm and video monitoring. Datacenter doors have alarms that will report when being opened or when they remain open
passed a programmed length of time. Doors can also be programmed to display the live CCTV image when a door alarm is
triggered. Additionally, the Control Room Supervisor constantly monitors a live feed of camera views from high security
and high traffic areas. Datacenter Access Tool (DCAT) is used to control access badge management (creation and
modification). Access card and biometric hand geometry and fingerprint readers are programmed and monitored through
the alarm monitoring system. Alarms are monitored and responded to by the Control Room Supervisor stationed 24x7 in
MICROSOFT CONFIDENTIAL – NDA REQUIRED 103
Cloud Implementation Guide for NERC Audits

the Secure Operations Center (SOC). During a response situation, the Control Room Supervisor utilizes cameras in the area
of the incident being investigated to give the responder real-time information.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 496 Covers NIST 800-53 PE-6(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.6

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.6 Physical Access Control Systems Monitor each Physical Access An example of evidence may include, but is
(PACS) associated with: Control System for unauthorized not limited to, documentation of controls
• High Impact BES Cyber physical access to a Physical Access that monitor for unauthorized physical
Systems, or Control System. access to a PACS.
• Medium Impact BES Cyber
Systems with External
Routable Connectivity

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

Access control devices in Azure datacenters are linked to the physical security system where device status is monitored
continuously. If an access control device stops working, the Control Room Supervisor is alerted immediately of device
malfunction. Moreover, all access control devices are under constant video surveillance to provide physical access
monitoring of alarm points.

NIST 800-53 PE-3 Physical Access Control: Physical access devices within Azure datacenters are inventoried on at least an
annual basis. Keys and temporary access badges are inventoried multiple times a day at the beginning of each shift. Access
badge readers and similar access devices are linked to the physical security system where status is continuously
represented.

NIST 800-53 PE-6 Monitoring Physical Access: Physical access is monitored by implementing security devices and processes
at the datacenters. Examples include 24x7 electronic monitoring of access control, alarm and video systems, as well as
24x7 on-site security patrols of the facility and grounds. A Control Room Supervisor is located in the Secure Operations
Center (SOC) at all times to provide monitoring of physical access in the datacenter. The Control Room Supervisor monitors
MICROSOFT CONFIDENTIAL – NDA REQUIRED 104
Cloud Implementation Guide for NERC Audits

live camera feeds within the datacenter as well as the alarm monitoring system reports from all physical security access
devices within the datacenter. Physical access is reported in the alarm monitoring system as approved or failed. Failed
access results in an alarm status that requires action by the Control Room Supervisor. The Control Room Supervisor can
dispatch a responder for further investigation if needed. The physical access logs in the alarm monitoring system are
reviewed continuously, but are also available log files for subsequent investigative review.

CCTV is employed to monitor physical access to the datacenter and the information system. The CCTV is linked to the
building alarm monitoring system to provide physical access monitoring of alarm points. Cameras are positioned to
monitor perimeter doors, facility entrances and exits, all colocation rows and aisles, all racks, caged areas, high-security
areas, shipping and receiving, facility external areas such as parking lots and other areas of the facility.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 489 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 494 Covers NIST 800-53 PE-6

R1 Part 1.7

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.7 Physical Access Control Systems Issue an alarm or alert in response to An example of evidence may include, but is
(PACS) associated with: detected unauthorized physical not limited to, language in the physical
• High Impact BES Cyber access to a Physical Access Control security plan that describes the issuance of
Systems, or System to the personnel identified in an alarm or alert in response to
• Medium Impact BES Cyber the BES Cyber Security Incident unauthorized physical access to Physical
Systems with External response plan within 15 minutes of Access Control Systems and additional
Routable Connectivity the detection. evidence that the alarm or alerts was issued
and communicated as identified in the BES
Cyber Security Incident Response Plan, such
as alarm or alert logs, cell phone or pager
logs, or other evidence that the alarm or
alert was generated and communicated.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

MICROSOFT CONFIDENTIAL – NDA REQUIRED 105

Cloud Implementation Guide for NERC Audits

NIST 800-53 PE-6(1) Monitoring Physical Access | Intrusion Alarms / Surveillance Equipment: In addition to the 24x7 onsite
security, Azure datacenters (leased and fully-managed) also utilize alarm monitoring systems. This provides real-time
alarm and video monitoring. Datacenter doors have alarms that will report when being opened or when they remain open
passed a programmed length of time. Doors can also be programmed to display the live CCTV image when a door alarm is
triggered. Additionally, the Control Room Supervisor constantly monitors a live feed of camera views from high security
and high traffic areas. Datacenter Access Tool (DCAT) is used to control access badge management (creation and
modification). Access card and biometric hand geometry and fingerprint readers are programmed and monitored through
the alarm monitoring system. Alarms are monitored and responded to by the Control Room Supervisor stationed 24x7 in
the Secure Operations Center (SOC). During a response situation, the Control Room Supervisor utilizes cameras in the area
of the incident being investigated to give the responder real-time information.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 496 Covers NIST 800-53 PE-6(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.8

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.8 High Impact BES Cyber Systems and Log (through automated means or An example of evidence may include, but is
their associated: by personnel who control entry) not limited to, language in the physical
1. EACMS; and entry of each individual with security plan that describes logging and
2. PCA authorized unescorted physical recording of physical entry into each
access into each Physical Security Physical Security Perimeter and additional
Medium Impact BES Cyber Systems
Perimeter, with information to evidence to demonstrate that this logging
with External Routable Connectivity
identify the individual and date and has been implemented, such as logs of
and their associated:
time of entry. physical access into Physical Security
1. EACMS; and
Perimeters that show the individual and the
2. PCA
date and time of entry into Physical Security
Perimeter.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-3 Physical Access Control: Access authorizations at Azure datacenters are managed through the
Datacenter Access Tool (DCAT). DCAT contains the authorized access lists of personnel who have been approved by the

MICROSOFT CONFIDENTIAL – NDA REQUIRED 106

Cloud Implementation Guide for NERC Audits

DCM team. Access to areas within the datacenter is granted based on the least privilege principle. Before a person can be
granted physical access to a datacenter, they must have a DCAT request approved by the DCM team. The DCM team
reviews the request for a valid business justification and for appropriate access levels. Upon arriving at the datacenter,
the individual on the request must have their identification verified by the security against a Microsoft identification badge
or government issued identification card. All accesses to Azure datacenter facilities are logged and audited.

NIST 800-53 PE-6 Monitoring Physical Access: To access an Azure datacenter, a person must have a Datacenter Access
Tool (DCAT) request approved by the Datacenter Management (DCM) team. In order to enter an Azure datacenter, a
person must check-in with the Security Operations Center (SOC) that is manned 24x7. A person’s physical access within
the datacenter is reviewed continuously by the Control Room Supervisor in the SOC. The Control Room Supervisor
monitors live camera feeds within the datacenter as well as the alarm monitoring system reports from all physical security
access devices within the datacenter. Physical access is reported in the alarm monitoring system as approved or failed.
Failed access results in an alarm status that requires action by the Control Room Supervisor. The Control Room Supervisor
can dispatch a responder for further investigation if needed. The physical access logs in the alarm monitoring system are
reviewed continuously but are also available in log files for subsequent investigative review.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 489 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 494 Covers NIST 800-53 PE-6

R1 Part 1.9

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures

1.9 High Impact BES Cyber Systems and Retain physical access logs of entry An example of evidence may include, but
their associated: of individuals with authorized is not limited to, dated documentation
1. EACMS; and unescorted physical access into each such as logs of physical access into
2. PCA Physical Security Perimeter for at Physical Security Perimeters that show the
least ninety calendar days. date and time of entry into Physical
Medium Impact BES Cyber Systems
Security Perimeter.
with External Routable Connectivity
and their associated:
1. EACMS; and
2. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 107
Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: Yes

CIP-006-6 R1.9 requires that physical access logs of individuals with authorized unescorted physical access be retained for
at least 90 days; however, FedRAMP does not prescribe the retention period for physical access audit logs. However,
FedRAMP has an overall requirement in NIST 800-53 AU-11 that all audit records be retained for at least 90 days to provide
support for after-the-fact investigations of security incidents to meet regulatory and organizational information retention
requirements. Moreover, CIP-006-6 R2.3 requires that visitor logs be retained for at least 90 days but in this case FedRAMP
requires that visitor logs be maintained for a minimum of one year and reviewed at least monthly. Microsoft stores Azure
datacenter physical access logs for authorized individuals and visitors within the DCAT database for possible future
investigations and retains them for 3 years. This policy is maintained by the DCAT Operations team.

NIST 800-53 AU-11 Audit Record Retention: For Infrastructure, Azure implements audit record retention through
maintaining all audit records for a minimum of one year. C+AI Security has developed an archiving infrastructure to
securely store audit records on servers dedicated to archival purposes. The servers are designed to verify the integrity of
archived files and allows authorized user to browse to an archive location. Audit records are stored in centralized log
servers that are protected against alteration.

NIST 800-53 PE-3 Physical Access Control: Access authorizations at Azure datacenters are managed through the
Datacenter Access Tool (DCAT). DCAT contains the authorized access lists of personnel who have been approved by the
DCM team. Access to areas within the datacenter is granted based on the least privilege principle. Before a person can be
granted physical access to a datacenter, they must have a DCAT request approved by the DCM team. The DCM team
reviews the request for a valid business justification and for appropriate access levels. Upon arriving at the datacenter,
the individual on the request must have their identification verified by the security against a Microsoft identification badge
or government issued identification card. All accesses to Azure datacenter facilities are logged and audited.

NIST 800-53 PE-6 Monitoring Physical Access: To access an Azure datacenter, a person must have a Datacenter Access
Tool (DCAT) request approved by the Datacenter Management (DCM) team. In order to enter an Azure datacenter, a
person must check-in with the Security Operations Center (SOC) that is manned 24x7. A person’s physical access within
the datacenter is reviewed continuously by the Control Room Supervisor (CRS) in the SOC. The CRS monitors live camera
feeds within the datacenter as well as the alarm monitoring system reports from all physical security access devices within
the datacenter. Physical access is reported in the alarm monitoring system as approved or failed. Failed access results in
an alarm status that requires action by the CRS. The CRS can dispatch a responder for further investigation if needed. The
physical access logs in the alarm monitoring system are reviewed continuously but are also available in log files for
subsequent investigative review.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 222 Covers NIST 800-53 AU-11
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 489 Covers NIST 800-53 PE-3
“ “ “ “ 494 Covers NIST 800-53 PE-6

MICROSOFT CONFIDENTIAL – NDA REQUIRED 108

Cloud Implementation Guide for NERC Audits

R1 Part 1.10

CIP-006-6 Table R1 – Physical Security Plan

Part Applicable Systems Requirements Measures
An example of evidence may include, but is
1.10 High Impact BES Cyber Systems and Restrict physical access to cabling
not limited to, records of the Responsible
their associated: and other nonprogrammable
Entity’s implementation of the physical
• PCA communication components used
access restrictions (e.g., cabling and
for connection between applicable
Medium Impact BES Cyber Systems at components secured through conduit or
Cyber Assets within the same
Control Centers and their associated: secured cable trays) encryption, monitoring,
Electronic Security Perimeter in
• PCA or equally effective logical protections.
those instances when such cabling
and components are located outside
of a Physical Security Perimeter.
Where physical access restrictions to
such cabling and components are
not implemented, the Responsible
Entity shall document and
implement one or more of the
following:
• encryption of data that
transits such cabling and
components; or
• monitoring the status of the
communication link
composed of such cabling
and components and
issuing an alarm or alert in
response to detected
communication failures to
the personnel identified in
the BES Cyber Security
Incident response plan
within 15 minutes of
detection; or
• an equally effective logical
protection.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-9 Power Equipment and Cabling: Azure provides protective spaces and appropriate labeling for cables.
Azure infrastructure equipment—for example, cables, electrical lines, and backup generators—must be placed in
environments that have been engineered for protection against environmental risks such as theft, fire, explosives, smoke,
water, dust, vibration, earthquake, harmful chemicals, electrical interference, power outages, electrical disturbances
(spikes). All portable online services’ assets (e.g. racks, servers, network devices) must be locked or fastened in place in
order to provide protection against theft or movement damage. Power and information system cables within any Azure
MICROSOFT CONFIDENTIAL – NDA REQUIRED 109
Cloud Implementation Guide for NERC Audits

environment are labeled appropriately and protected against interception or damage. Power and information system
cables are separated from each other at all points within an environment to avoid interference. Power cables are run
under the floors, overhead in cable trays and within cabinets for protection from moving parts and accidental damage. All
electrical spaces are behind card readers or additional key locks as appropriate. Access hallways as well as exterior
entrances and equipment yards approaching the protective spaces are all monitored via video surveillance.

Power systems also utilize redundancy as a form of protection. Datacenters utilize multiple power/utility feeds into the
facility as well as redundant configurations of generators and UPS systems. Generator and UPS system components
undergo regular maintenance procedures to maintain the systems in proper working order.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 498 Covers NIST 800-53 PE-9
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement one or more documented visitor control program(s) that include each
of the applicable requirement parts in CIP-006-6 Table R2 – Visitor Control Program. [Violation Risk Factor:
Medium] [Time Horizon: Same Day Operations.]
M2. Evidence must include one or more documented visitor control programs that collectively include each of the
applicable requirement parts in CIP-006-6 Table R2 – Visitor Control Program and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R2 Part 2.1

CIP-006-6 Table R2 – Visitor Control Program

Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems and Require continuous escorted access An example of evidence may include, but is
their associated: of visitors (individuals who are not limited to, language in a visitor control
1. EACMS; and provided access but are not program that requires continuous escorted
2. PCA authorized for unescorted physical access of visitors within Physical Security
access) within each Physical Security Perimeters and additional evidence to
Medium Impact BES Cyber Systems
Perimeter, except during CIP demonstrate that the process was
with External Routable Connectivity
Exceptional Circumstances. implemented, such as visitor logs.
and their associated:
1. EACMS; and
2. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
MICROSOFT CONFIDENTIAL – NDA REQUIRED 110
Cloud Implementation Guide for NERC Audits

evidence, including links to the appropriate page, are recommended.

Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-3 Physical Access Control: All visitors that have approved access to the datacenter are designated as
“Escort Only” on their badges and are required to remain with their escorts at all times. Escorted visitors do not have any
access levels granted to them and can only travel on the access of their escorts. Escorts monitor all activities of their visitor
while in the datacenter.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 489 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.2

CIP-006-6 Table R2 – Visitor Control Program

Part Applicable Systems Requirements Measures

2.2 High Impact BES Cyber Systems and Require manual or automated An example of evidence may include, but is
their associated: logging of visitor entry into and exit not limited to, language in a visitor control
1. EACMS; and from the Physical Security Perimeter program that requires continuous escorted
2. PCA that includes date and time of the access of visitors within Physical Security
initial entry and last exit, the visitor’s Perimeters and additional evidence to
Medium Impact BES Cyber Systems
name, and the name of an individual demonstrate that the process was
with External Routable Connectivity
point of contact responsible for the implemented, such as dated visitor logs that
and their associated:
visitor, except during CIP Exceptional include the required information.
1. EACMS; and
Circumstances.
2. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-8 Visitor Access Records: Visitor datacenter access records are maintained in Datacenter Access Tool
(DCAT) in the form of approved DCAT requests. DCAT requests can only be approved by the Datacenter Management
(DCM) team. All visitor access requests to Azure datacenters is recorded in DCAT and is available for future possible
investigations. As described in PE-03, visitors are required to be escorted at all times and are not granted any access to
Azure datacenters. The escort’s access within the datacenter is logged within Lenel Onguard Alarm Monitoring System
MICROSOFT CONFIDENTIAL – NDA REQUIRED 111
Cloud Implementation Guide for NERC Audits

and if necessary can be correlated to the visitor for future review. Visitor access is being reviewed continuously by the
assigned escort and by the Control Room Supervisor (CRS) via CCTV and the alarm monitoring system.

Visitors with an approved DCAT access request will have their access request reviewed at the time their identification is
verified against a form of government issued ID or Microsoft issued badge. Visitors approved for escorted access are issued
a self-expiring sticky badge. Additionally, when a visitor concludes their visit by returning their sticky badge to the CRS,
the CRS terminates the visitor’s DCAT access record during a final review. In the event that a visitor leaves with their visitor
badge, the badge expires automatically within 24 hours and the words “VOID” appear in red.. Azure maintains visitor
access records within the DCAT database for possible future investigations.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 497 Covers NIST 800-53 PE-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.3

CIP-006-6 Table R2 – Visitor Control Program

Part Applicable Systems Requirements Measures

2.3 High Impact BES Cyber Systems and Retain visitor logs for at least ninety An example of evidence may include, but is
their associated: calendar days. not limited to, documentation showing logs
1. EACMS; and have been retained for at least ninety
2. PCA calendar days.
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS; and
2. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure security controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

The organization is required to maintain visitor access records to the facility where the information system resides for a
minimum of one year per FedRAMP assignment. Moreover, visitor access records must be reviewed at least monthly.

NIST 800-53 AU-11 Audit Record Retention: For Infrastructure, Azure implements audit record retention through
maintaining all audit records for a minimum of one year. C+AI Security has developed an archiving infrastructure to
MICROSOFT CONFIDENTIAL – NDA REQUIRED 112
Cloud Implementation Guide for NERC Audits

securely store audit records on servers dedicated to archival purposes. The servers are designed to verify the integrity of
archived files and allows authorized user to browse to an archive location. Audit records are stored in centralized log
servers that are protected against alteration.

NIST 800-53 PE-8 Visitor Access Records: Visitor datacenter access records are maintained in Datacenter Access Tool
(DCAT) in the form of approved DCAT requests. DCAT requests can only be approved by the Datacenter Management
(DCM) team. All visitor access requests to Azure datacenters is recorded in DCAT and is available for future possible
investigations. Visitors are required to be escorted at all times and are not granted any access to Azure datacenters. The
escort’s access within the datacenter is logged within Lenel Onguard Alarm Monitoring System and if necessary can be
correlated to the visitor for future review. As described in PE-2, datacenter access is reviewed quarterly. Microsoft stores
Azure datacenter physical access logs for authorized individuals and visitors within the DCAT database for possible future
investigations and retains them for 3 years. This policy is maintained by the DCAT Operations team.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 222 Covers NIST 800-53 AU-11
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 496-497 Covers NIST 800-53 PE-8

MICROSOFT CONFIDENTIAL – NDA REQUIRED 113

Cloud Implementation Guide for NERC Audits

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall implement one or more documented Physical Access Control System maintenance
and testing program(s) that collectively include each of the applicable requirement parts in CIP-006-6 Table R3 –
Maintenance and Testing Program. [Violation Risk Factor: Lower] [Time Horizon: Long Term Planning].
M3. Evidence must include each of the documented Physical Access Control System maintenance and testing
programs that collectively include each of the applicable requirement parts in CIP-006-6 Table R3 – Maintenance
and Testing Program and additional evidence to demonstrate implementation as described in the Measures
column of the table.

R3 Part 3.1

CIP-006-6 Table R3 – Physical Access Control System Maintenance and Testing Program
Part Applicable Systems Requirements Measures

3.1 Physical Access Control Systems Maintenance and testing of each An example of evidence may include, but is
(PACS) associated with: Physical Access Control System and not limited to, a maintenance and testing
• High Impact BES Cyber locally mounted hardware or devices program that provides for testing each
Systems, or at the Physical Security Perimeter at Physical Access Control System and locally
• Medium Impact BES Cyber least once every 24 calendar months mounted hardware or devices associated
Systems with External to ensure they function properly. with each applicable Physical Security
Routable Connectivity Perimeter at least once every 24 calendar
months and additional evidence to
Locally mounted hardware or devices
demonstrate that this testing was done,
at the Physical Security Perimeter
such as dated maintenance records, or
associated with:
other documentation showing testing and
• High Impact BES Cyber maintenance has been performed on each
Systems, or applicable device or system at least once
• Medium Impact BES Cyber every 24 calendar months.
Systems with External
Routable Connectivity

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical infrastructure controls applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

FedRAMP PE-3(f) requires that all physical access control devices be inventoried at least annually; however, FedRAMP
does not prescribe maintenance and testing of physical access control devices at least every 24 months to ensure they
function properly. Microsoft complies with FedRAMP requirement that all access control devices be inventoried at least
annually. Moreover, access control devices in Azure datacenters are linked to the physical security system where device
status is monitored continuously. Therefore, it is not necessary to have separate testing every 24 months to ensure
devices function properly. If an access control device stops working, the Control Room Supervisor is alerted immediately
of device malfunction.

NIST 800-53 PE-3 Physical Access Control: Physical access devices within Azure datacenters are inventoried on at least an
annual basis. Keys and temporary access badges are inventoried multiple times a day at the beginning of each shift. Access
badge readers and similar access devices are linked to the physical security system where status is continuously
MICROSOFT CONFIDENTIAL – NDA REQUIRED 114
Cloud Implementation Guide for NERC Audits

represented.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 489 Covers NIST 800-53 PE-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 115

Cloud Implementation Guide for NERC Audits

CIP-007-6 – Cyber Security – System Security Management

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-007-6 Table R1 – Ports and Services. [Violation Risk Factor: Medium]
[Time Horizon: Same Day Operations.]
M1. Evidence must include the documented processes that collectively include each of the applicable requirement
parts in CIP-007-6 Table R1 – Ports and Services and additional evidence to demonstrate implementation as
described in the Measures column of the table.

R1 Part 1.1

CIP-007-6 Table R1– Ports and Services

Part Applicable Systems Requirements Measures

1.1 High Impact BES Cyber Systems and Where technically feasible, enable Examples of evidence may include, but are
their associated: only logical network accessible ports not limited to:
1. EACMS; that have been determined to be • Documentation of the need for all
2. PACS; and needed by the Responsible Entity, enabled ports on all applicable
3. PCA including port ranges or services Cyber Assets and Electronic Access
where needed to handle dynamic Points, individually or by group.
Medium Impact BES Cyber Systems
with External Routable Connectivity
ports. If a device has no provision • Listings of the listening ports on
for disabling or restricting logical the Cyber Assets, individually or by
and their associated:
ports on the device then those ports group, from either the device
1. EACMS;
that are open are deemed needed. configuration files, command
2. PACS; and
output (such as netstat), or
3. PCA network scans of open ports; or
• Configuration files of host-based
firewalls or other device level
mechanisms that only allow
needed ports and deny all others.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring only essential functions, ports, protocols, and services are enabled for assets
under customer control. All other functions, ports, protocols, and services should be disabled by default. Customers should
review documentation on Azure network security for more information.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-7 Least Functionality: Microsoft Azure takes into consideration the United States Government
Configuration Baseline (USGCB) in development of all base operating system images, configuration scripts, and
configuration files deployed within the system. These base images include essential functions, ports, protocols, and
services. All other functions, ports, protocols, and services are disabled by default. Service teams must go through an
approval process to have a port opened, or a function, protocol, or service enabled.

For network devices, the Azure Networking Standards and Architecture team sets the configuration baseline standards
MICROSOFT CONFIDENTIAL – NDA REQUIRED 116
Cloud Implementation Guide for NERC Audits

for all network devices, using recommended configurations specific to each hardware vendor, and makes updates
periodically based upon recommendations from the vendor. These base configurations include essential functions, ports,
protocols, and services. All other functions, ports, protocols, and services are disabled by default.

NIST 800-53 CM-7(1) Least Functionality | Periodic Review: Microsoft Azure software and hardware configurations and
Access Control Lists (ACLs) are reviewed at least monthly to identify any unnecessary or non-secure functions, ports,
protocols, and services. Any function, port, protocol, or service identified as unnecessary or non-secure during the review
process is disabled.

NIST 800-53 SC-7(5) Boundary Protection | Deny by Default / Allow by Exception: The over-arching principle of Microsoft
Azure network security is deny-by-default, which means allowing only connection and communication that is necessary
for systems to operate, blocking all other ports, protocols, and connections by default. Azure only allows connections and
communication that are necessary to operate the system. Connections are managed at the system boundary using Azure
Networking boundary protection devices. Connections within the boundary are managed using:

• IP Filtering
• VFP Filtering (for virtual machines)
• Host-based firewalls
• Guest firewalls (for virtual machines)

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 293 Covers NIST 800-53 CM-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 295 Covers NIST 800-53 CM-7(1)
“ “ “ “ 626 Covers NIST 800-53 SC-7(5)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 117

Cloud Implementation Guide for NERC Audits

R1 Part 1.2

CIP-007-6 Table R1– Ports and Services

Part Applicable Systems Requirements Measures

1.2 High Impact BES Cyber Systems and Protect against the use of An example of evidence may include, but is
their associated: unnecessary physical input/output not limited to, documentation showing
1. PCA; and ports used for network connectivity, types of protection of physical input/output
2. Nonprogrammable console commands, or Removable ports, either logically through system
communication components Media. configuration or physically using a port lock
located inside both a PSP or signage.
and an ESP.
Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. PCA; and
2. Nonprogrammable
communication components
located inside both a PSP
and an ESP.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for physical input/output ports used for network connectivity, console commands, or
Removable Media for assets deployed in the cloud.

Cloud Provider Responsibility: Yes

As described in PE-6 for CIP-006-6 R1.4, Azure servers are located in secured facilities that employ 24x7 electronic
monitoring of access control, alarm, and video systems, as well as 24x7 on-site security patrols of the facility and grounds.
The Control Room Supervisor monitors live camera feeds within the datacenter as well as the alarm monitoring system
reports from all physical security access devices within the datacenter. CCTV is employed to monitor physical access to
the datacenter, including perimeter doors, all collocation rows and aisles, all racks, caged areas, etc. Moreover, Azure
compute nodes rely on logical protection in the physical security baseline for all bare metal deployments to restrict access
to physical I/O ports such as serial and USB ports. Access to devices connected to serial and USB ports is not possible from
Azure Virtual Machines (VMs) because VMs do not have the corresponding drivers.

NIST 800-53 CM-8(3) Information System Component Inventory | Automated Unauthorized Component Detection: Azure
does not wait to disable network access for unauthorized components/devices in the information system. When network
devices are deployed, ports are turned off by default. Unassigned ports are put into a Virtual Local Area Network (VLAN)
that is not configured at the Layer 3 and has no provisioned servers in it. Therefore, even if ports were enabled, there
would be no access to any provisioned servers, and traffic would not have the ability to leave the subnet. To prevent IP
spoofing, Azure uses Access Control Lists (ACLs) on the Layer 3 to deny packets sourced by the subnet from entering that
subnet.

Additionally, physical access controls are employed in the datacenters to mitigate the unauthorized addition of new
devices into the environment. Physical access to the devices to add additional ports is also disabled within the
environment.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 118

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 307 Covers NIST 800-53 CM-8(3)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-007-6 Table R2 – Security Patch Management. [Violation Risk Factor:
Medium] [Time Horizon: Operations Planning].
M2. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-007-6 Table R2 – Security Patch Management and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R2 Part 2.1

CIP-007-6 Table R2 – Security Patch Management

Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems and A patch management process for An example of evidence may include, but is
their associated: tracking, evaluating, and installing not limited to, documentation of a patch
1. EACMS; cyber security patches for applicable management process and documentation
2. PACS; and Cyber Assets. The tracking portion or lists of sources that are monitored,
3. PCA shall include the identification of a whether on an individual BES Cyber System
source or sources that the or Cyber Asset basis.
Responsible Entity tracks for the
Medium Impact BES Cyber Systems release of cyber security patches for
and their associated: applicable Cyber Assets that are
1. EACMS; updateable and for which a patching
2. PACS; and source exists.
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that end users are using secure browsers and properly patched information
systems to access Microsoft Azure. Moreover, Registered Entity is responsible for patching base operating system images
in guest Virtual Machines (VMs) under its control, e.g., Infrastructure as a Service (IaaS) images provisioned from the image
gallery or deployed directly by the Registered Entity. Microsoft does not have access to customer Azure IaaS VMs and
cannot automatically patch these VMs. Customers should review Update Management Solution in Azure for guidance on
how to configure an automated patching schedule for Azure IaaS VMs.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 119
Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: Yes

NIST 800-53 SI-2 Flaw Remediation: Azure implements flaw remediation through the C+AI Security Team. C+AI tracks
multiple sources of information for vulnerability-related data. These sources include: Microsoft Security Response Center
(MSRC), vendor websites, and other third-party websites. Updates tracked by these sources are monitored by C+AI
Security for possible inclusion on its monthly Security Updates Advisory. Only a subset of these updates, based on their
applicability to the Azure environment, may be required by C+AI Security. Microsoft publishes bulletins that include
specific information relevant to the security update being released.

C+AI Security has developed a comprehensive methodology to verify the status of software updates installed in the Azure
environment. Azure uses automated vulnerability scanning tools to determine whether a required security flaw has been
remediated properly and the date of installation of security updates. These tools collect information from each server and
compare it to the requirements defined for each security update or vulnerability ID.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 665, 668 Covers NIST 800-53 SI-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.2

CIP-007-6 Table R2 – Security Patch Management

Part Applicable Systems Requirements Measures

2.2 High Impact BES Cyber Systems and At least once every 35 calendar days, An example of evidence may include, but is
their associated: evaluate security patches for not limited to, an evaluation conducted by,
1. EACMS; applicability that have been released referenced by, or on behalf of a Responsible
2. PACS; and since the last evaluation from the Entity of security-related patches released
3. PCA source or sources identified in Part by the documented sources at least once
2.1. every 35 calendar days.

Medium Impact BES Cyber Systems

and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that end users are using secure browsers and properly patched information

MICROSOFT CONFIDENTIAL – NDA REQUIRED 120

Cloud Implementation Guide for NERC Audits

systems to access Microsoft Azure. Moreover, Registered Entity is responsible for patching base operating system images
in guest Virtual Machines (VMs) under its control, e.g., Infrastructure as a Service (IaaS) images provisioned from the image
gallery or deployed directly by the Registered Entity. Microsoft does not have access to customer Azure IaaS VMs and
cannot automatically patch these VMs. Customers should review Update Management Solution in Azure for guidance on
how to configure an automated patching schedule for Azure IaaS VMs.

Cloud Provider Responsibility: Yes

NIST 800-53 SI-2 Flaw Remediation: Azure infrastructure is monitored using automated vulnerability scanning tools. These
tools are configured on the basis of knowledge provided by MSRC, vendors, and other sources, including analysis by C+AI
Security. The Vulnerability Management Program Manager conducts the following activities on a monthly basis:

• Thursday Prior to Release

Conference call with Azure stakeholders to review updates that will be required in the Azure environment, based on the
data provided by MSRC. Minutes from this call are recorded and saved for historical understanding of the rationale used
to determine which updates were required in the past.

• Release Day (Second Tuesday of Every Month)

- Review via conference call of detailed information provided by MSRC with Azure stakeholders for inclusion on the list of
updates required in the Azure environment.
- Consensus reached with Azure stakeholders on the required security updates for the Azure environment. Meeting
minutes record attendees and any concerns regarding all released security updates.
- E-mail communication to broad distribution list that includes: list of required updates; download location of required
software and deadline for installation of the updates. After the email communication is sent, the same information is
posted to the internal C+E Security website for future reference.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 665-666 Covers NIST 800-53 SI-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 121

Cloud Implementation Guide for NERC Audits

R2 Part 2.3

CIP-007-6 Table R2 – Security Patch Management

Part Applicable Systems Requirements Measures

2.3 High Impact BES Cyber Systems and For applicable patches identified in Examples of evidence may include, but are
their associated: Part 2.2, within 35 calendar days of not limited to:
1. EACMS; the evaluation completion, take one • Records of the installation of the
2. PACS; and of the following actions: patch (e.g., exports from
3. PCA • Apply the applicable automated patch management
patches; or tools that provide installation date,
• Create a dated mitigation verification of BES Cyber System
Medium Impact BES Cyber Systems plan; or Component software revision, or
and their associated: • Revise an existing registry exports that show
1. EACMS; mitigation plan. software has been installed); or
2. PACS; and • A dated plan showing when and
3. PCA Mitigation plans shall include the
how the vulnerability will be
Responsible Entity’s planned actions
addressed, to include
to mitigate the vulnerabilities
documentation of the actions to be
addressed by each security patch
taken by the Responsible Entity to
and a timeframe to complete these
mitigate the vulnerabilities
mitigations.
addressed by the security patch
and a timeframe for the
completion of these mitigations.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that patch management process is properly maintained and documented for
assets under its control.

Cloud Provider Responsibility: Yes

NIST 800-53 SI-2 Flaw Remediation: Most security updates are required to be installed within 30 calendar days of the
notification of the update’s availability. C+AI Security requires on occasion an expedited timeline for the application of
security updates based on the following criteria:

• Applications or services affected

• Availability of reliable exploit code
• Prevalence of exploit activity

Information collected from C+AI Security monitoring efforts or an increase on the risk level faced by Azure servers may be
used to expedite remediation of outstanding security vulnerabilities after the original deadline was set.

C+AI Security has developed a comprehensive methodology to verify the status of software updates installed in the Azure
environment. Azure uses automated vulnerability scanning tools to determine whether a required security flaw has been
remediated properly and the date of installation of security updates. These tools collect information from each server and
compare it to the requirements defined for each security update or vulnerability ID. Tools are updated at least on a
monthly basis to keep abreast of the changing threat environment.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 122

Cloud Implementation Guide for NERC Audits

NIST 800-53 CA-5 Plan of Action and Milestones: Microsoft Azure develops Plan of Action and Milestones (POA&M) in
accordance with the Office of Management and Budget (OMB) guidance and FedRAMP requirements. The POA&M is
submitted as part of the Microsoft Azure Security Authorization Package provided to FedRAMP.

Microsoft updates the POA&M on at least a monthly basis based on the findings of the security control assessments and
ongoing continuous monitoring activities, including vulnerability scanning. Microsoft includes an action step to remediate
any high and medium items from ongoing assessments and vulnerability scans (if any) in the monthly POA&M submission.
For any high and medium items noted, Microsoft provides a high-level description of the issue and the remediation plan.
The raw scan reports contain details on any issues noted and are made available to FedRAMP on a monthly basis.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 666, 668 Covers NIST 800-53 SI-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 239 Covers NIST 800-53 CA-5

R2 Part 2.4

CIP-007-6 Table R2 – Security Patch Management

Part Applicable Systems Requirements Measures

2.4 High Impact BES Cyber Systems and For each mitigation plan created or An example of evidence may include, but is
their associated: revised in Part 2.3, implement the not limited to, records of implementation of
1. EACMS; plan within the timeframe specified mitigations.
2. PACS; and in the plan, unless a revision to the
3. PCA plan or an extension to the
timeframe specified in Part 2.3 is
Medium Impact BES Cyber Systems
approved by the CIP Senior Manager
and their associated:
or delegate.
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that patch management process is properly documented and implemented
for assets under its control.

Cloud Provider Responsibility: Yes

NIST 800-53 CA-5 Plan of Action and Milestones: Microsoft Azure develops Plan of Action and Milestones (POA&M) in
accordance with the Office of Management and Budget (OMB) guidance and FedRAMP requirements. The POA&M is
submitted as part of the Microsoft Azure Security Authorization Package provided to FedRAMP.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 123
Cloud Implementation Guide for NERC Audits

Microsoft updates the POA&M on at least a monthly basis based on the findings of the security control assessments and
ongoing continuous monitoring activities, including vulnerability scanning. Microsoft includes an action step to remediate
any high and medium items from ongoing assessments and vulnerability scans (if any) in the monthly POA&M submission.
For any high and medium items noted, Microsoft provides a high-level description of the issue and the remediation plan.
The raw scan reports contain details on any issues noted and are made available to FedRAMP on a monthly basis.

NIST 800-53 SI-2 Flaw Remediation: C+AI Security has developed a comprehensive methodology to verify the status of
software updates installed in the Azure environment. Azure uses automated vulnerability scanning tools to determine
whether a required security flaw has been remediated properly and the date of installation of security updates. These
tools collect information from each server and compare it to the requirements defined for each security update or
vulnerability ID. Tools are updated at least on a monthly basis to keep abreast of the changing threat environment.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 239 Covers NIST 800-53 CA-5
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 668 Covers NIST 800-53 SI-2

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-007-6 Table R3 – Malicious Code Prevention. [Violation Risk Factor:
Medium] [Time Horizon: Same Day Operations].
M3. Evidence must include each of the documented processes that collectively include each of the applicable
requirement parts in CIP-007-6 Table R3 – Malicious Code Prevention and additional evidence to demonstrate
implementation as described in the Measures column of the table.

R3 Part 3.1

CIP-007-6 Table R3 – Malicious Code Prevention

Part Applicable Systems Requirements Measures

3.1 High Impact BES Cyber Systems and Deploy method(s) to deter, detect, An example of evidence may include, but is
their associated: or prevent malicious code. not limited to, records of the Responsible
1. EACMS; Entity’s performance of these processes
2. PACS; and (e.g., through traditional antivirus, system
3. PCA hardening, policies, etc.).
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and
3. PCA
MICROSOFT CONFIDENTIAL – NDA REQUIRED 124
Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
When accessing Microsoft Azure, Registered Entity is responsible for ensuring that its information systems are running
anti-malware software. Moreover, Registered Entity can deploy and enable Microsoft Antimalware for Azure based on
the needs of its application workloads, with either basic secure-by-default or advanced custom configuration, including
antimalware monitoring. Customers should review documentation on Microsoft Antimalware for Azure Cloud Services
and Virtual Machines.

Cloud Provider Responsibility: Yes

NIST 800-53 SI-3 Malicious Code Protection: The use of anti-malware software is a principal mechanism for protection of
Microsoft Azure assets from malicious software. The software detects and prevents the introduction of computer viruses,
malware, rootkits, worms, and other malicious software onto the service systems. Anti-malware software provides both
preventive and detective control over malicious software. Approved tools/solutions such as Microsoft Endpoint
Protection, Clam AV etc. is installed as part of the initial build on all systems, including all entry and exit points to the
information system.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 673 Covers NIST 800-53 SI-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R3 Part 3.2

CIP-007-6 Table R3 – Malicious Code Prevention

Part Applicable Systems Requirements Measures

3.2 High Impact BES Cyber Systems and Mitigate the threat of detected Examples of evidence may include, but are
their associated: malicious code. not limited to:
1. EACMS; • Records of response processes for
2. PACS; and malicious code detection
3. PCA • Records of the performance of
Medium Impact BES Cyber Systems these processes when malicious
and their associated: code is detected.
1. EACMS;
2. PACS; and
3. PCA

MICROSOFT CONFIDENTIAL – NDA REQUIRED 125

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity can deploy and enable Microsoft Antimalware for Azure based on the needs of its application workloads,
with either basic secure-by-default or advanced custom configuration, including antimalware monitoring. Registered
Entity is responsible for documenting processes for malicious code detection and retaining records of those processes.
Customers should review documentation on Microsoft Antimalware for Azure Cloud Services and Virtual Machines.

Cloud Provider Responsibility: Yes

NIST 800-53 SI-3 Malicious Code Protection: The following functions are centrally managed by the appropriate anti-
malware tool on each endpoint for each service team:

• Periodic scans of the file system (at least weekly)

• Real-time scans of files as they are downloaded, opened, or executed

Anti-malware tools detect files determined to be malicious and send alerts to Microsoft Azure administrators, which
triggers the incident response process. Customers, including government customers and US-CERT, will be notified as
required.

Azure by default quarantines malicious code identified from the anti-virus software system and does not immediately
delete them. Falsely identified malicious code is put in a quarantined folder on the system. System administrators can roll-
back quarantined files if they are falsely determined to be malicious code, in order to resolve impact to operations in the
system.

When anti-malware tools detect malware, they block the malware and an alert is generated and sent to Microsoft Azure
service team personnel, Microsoft Azure Security, and/or C+AI Security. The receiving personnel initiate the incident
response process. Incidents are tracked and resolved, and post mortem analysis is performed, as discussed in the Incident
Response (IR) family of controls (see CIP-008-5 Cyber Security – Incident Reporting and Response Planning).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 673-674 Covers NIST 800-53 SI-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 126

Cloud Implementation Guide for NERC Audits

R3 Part 3.3

CIP-007-6 Table R3 – Malicious Code Prevention

Part Applicable Systems Requirements Measures

3.3 High Impact BES Cyber Systems and For those methods identified in Part An example of evidence may include, but is
their associated: 3.1 that use signatures or patterns, not limited to, documentation showing the
1. EACMS; have a process for the update of the process used for the update of signatures or
2. PACS; and signatures or patterns. The process patterns.
3. PCA must address testing and installing
the signatures or patterns.
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
If Registered Entity deployed third-party anti-malware software into its Azure Virtual Machines, then Registered Entity
would be responsible for updating the signature files. Alternatively, Registered Entity can deploy and enable Microsoft
Antimalware for Azure based on the needs of its application workloads, with either basic secure-by-default or advanced
custom configuration, including antimalware monitoring. Microsoft Antimalware for Azure provides automatic download
and application of signature updates. Customers should review documentation on Microsoft Antimalware for Azure Cloud
Services and Virtual Machines.

Cloud Provider Responsibility: Yes

NIST 800-53 SI-3 Malicious Code Protection: Azure updates malicious code protection mechanisms for Anti-Virus Software
including signature definitions whenever new releases are available. Anti-virus Software is configured to use the
LiveUpdate service, where servers check for updates to the signature files every 4 hours and automatically updates them
accordingly. Each anti-malware package tracks the version of the software and what signatures are running. The automatic
download and application of signature updates at least daily from the vendor's virus definition site is centrally managed
by the appropriate anti-malware tool for each service team.

NIST 800-53 SI-2 Flaw Remediation: Testing of software updates related to flaw remediation must follow the standard
change management process. Testing of possible changes to the environment must be conducted in order to understand
possible impacts to the security and operations of the system. Testing must be conducted prior to approval, which is
necessary before changes to the production environment are implemented.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 127

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 673-675 Covers NIST 800-53 SI-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 668 Covers NIST 800-53 SI-2

R4 Supporting Evidence and Documentation

R4. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-007-6 Table R4 – Security Event Monitoring. [Violation Risk Factor:
Medium] [Time Horizon: Same Day Operations and Operations Assessment.]
M4. Evidence must include each of the documented processes that collectively include each of the applicable
requirement parts in CIP-007-6 Table R4 – Security Event Monitoring and additional evidence to demonstrate
implementation as described in the Measures column of the table.

R4 Part 4.1

CIP-007-6 Table R4 – Security Event Monitoring

Part Applicable Systems Requirements Measures

4.1 High Impact BES Cyber Systems and Log events at the BES Cyber System Examples of evidence may include, but are
their associated: level (per BES Cyber System not limited to, a paper or system generated
1. EACMS; capability) or at the Cyber Asset level listing of event types for which the BES
2. PACS; and (per Cyber Asset capability) for Cyber System is capable of detecting and,
3. PCA identification of, and after-the-fact for generated events, is configured to log.
investigations of, Cyber Security This listing must include the required types
Medium Impact BES Cyber Systems
Incidents that includes, as a of events.
and their associated:
minimum, each of the following
1. EACMS;
types of events:
2. PACS; and
4.1.1. Detected successful login
3. PCA
attempts;
4.1.2. Detected failed access
attempts and failed login
attempts;
4.1.3. Detected malicious code.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Customers are responsible for configuring auditing at the application, database, and Virtual Machine (VM) level as
necessary to capture the following events: successful and unsuccessful account logon events, account management

MICROSOFT CONFIDENTIAL – NDA REQUIRED 128

Cloud Implementation Guide for NERC Audits

events, object access, policy change, privilege functions, process tracking, and system events. For Web applications: all
administrator activity, authentication checks, authorization checks, data deletions, data access, data changes, and
permission changes. Customers can use Azure Security Center to prevent, detect, and respond to threats. Using Microsoft
global threat intelligence, security-related events from across customer’s Azure deployments are automatically collected
and analyzed to identify actual threats, offer insight into attacks, and suggest ways to remediate issues. Customers can
also leverage extensive logging capability built into Azure.

Cloud Provider Responsibility: No

Azure conducts extensive monitoring and logging of events at the platform level to protect the platform from intrusions
and malicious code using the latest threat telemetry. All customers benefit equally from this work; however, Azure does
not inspect, approve, or monitor individual customer applications.

NIST 800-53 SI-4 Information System Monitoring: Service teams have deployed active monitoring solutions that generate
alerts and audit logs. All service teams upload their logs to Geneva Monitoring, where they are aggregated and processed.
Reports are generated using Security Logging and Monitoring (SLAM). SLAM uses heuristics to identify unauthorized use
of the operating system. SLAM examines records to confirm that the system is functioning in an optimal, resilient, and
secure state. All servers act as monitoring devices and are configured to log all security-relevant events. Microsoft Azure
monitors all hosts in the environment. Suspicious events generate alarms and notifications to service team staff and
appropriate contingent staff. Any log event that indicates a potential violation of the Microsoft Azure Security Policy must
be immediately brought to the attention of Microsoft Azure Security.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 679-680 Covers NIST 800-53 SI-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R4 Part 4.2

CIP-007-6 Table R4 – Security Event Monitoring

Part Applicable Systems Requirements Measures

4.2 High Impact BES Cyber Systems and Generate alerts for security events Examples of evidence may include, but are
their associated: that the Responsible Entity not limited to, paper or system-generated
1. EACMS; determines necessitates an alert, listing of security events that the
2. PACS; and that includes, as a minimum, each of Responsible Entity determined necessitate
3. PCA the following types of events (per alerts, including paper or system generated
Cyber Asset or BES Cyber System list showing how alerts are configured.
Medium Impact BES Cyber Systems
capability):
with External Routable Connectivity
4.2.1. Detected malicious code
and their associated:
from Part 4.1; and
1. EACMS;
4.2.2. Detected failure of Part 4.1
2. PACS; and
event logging.
3. PCA

MICROSOFT CONFIDENTIAL – NDA REQUIRED 129

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Azure generates alerts for security events at the platform level and does not monitor individual customer applications.
Registered Entity is responsible for monitoring and logging of its applications deployed to Azure. Customers can use Azure
Security Center to prevent, detect, and respond to threats. Using Microsoft global threat intelligence, security-related
events from across customer’s Azure deployments are automatically collected and analyzed to identify actual threats,
offer insight into attacks, and suggest ways to remediate issues. Customers can also leverage extensive logging capability
built into Azure.

Cloud Provider Responsibility: No

NIST 800-53 SI-4 Information System Monitoring: All servers act as monitoring devices and are configured to log all
security-relevant events. Microsoft Azure monitors all hosts in the environment. Suspicious events generate alarms and
notifications to service team staff and appropriate contingent staff. Logs are aggregated in Geneva Monitoring. Azure
Infrastructure devices are configured to upload their logs to a central repository managed by C+AI Security. These logs are
aggregated and reports are generated by the C+AI Security Operations Center (SOC) team. C+AI SOC Monitoring has
developed an event audit policy that has the following features:

• HIDS – event IDs that represent highly suspicious activity

• OneIdentity – object access events for Windows system files that can be configured to audit high-value files using SACLs
• Account Management – monitors events related to account management from all Domain Controllers and member
servers, such as the addition of users to privileged security groups, etc.

Security incident and event management tool rules are generally tuned to alert on events of immediate concern, events
that need little correlation to prompt a preliminary investigation and attention of C+E SOC Tier 2 personnel. These audit
settings are deployed for all Azure supporting servers for the Azure Security Authorization Boundary.

NIST 800-53 SI-4(5) Information System Monitoring | System-Generated Alerts: Microsoft Azure Security has defined
requirements for active monitoring. Service teams configure active monitoring tools in accordance with these
requirements. Active monitoring tools include the Monitoring Agent (MA) and System Center Operations Manager
(SCOM), which are configured to provide real time alerts to Service Engineer Operations personnel in situations that
require immediate action. The indications of compromise or potential compromise are documented in the Microsoft Azure
Incident Response Plan.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 680 Covers NIST 800-53 SI-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 686 Covers NIST 800-53 SI-4(5)

MICROSOFT CONFIDENTIAL – NDA REQUIRED 130

Cloud Implementation Guide for NERC Audits

R4 Part 4.3

CIP-007-6 Table R4 – Security Event Monitoring

Part Applicable Systems Requirements Measures

4.3 High Impact BES Cyber Systems and Where technically feasible, retain Examples of evidence may include, but are
their associated: applicable event logs identified in not limited to, documentation of the event
1. EACMS; Part 4.1 for at least the last 90 log retention process and paper or system
2. PACS; and consecutive calendar days except generated reports showing log retention
3. PCA under CIP Exceptional configuration set at 90 days or greater.
Circumstances.
Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Customers are responsible for allocating sufficient audit record storage capacity for their storage solution and configuring
their auditing to reduce the likelihood of such capacity being exceeded. Customers can leverage extensive logging
capability built into Azure.

Cloud Provider Responsibility: No

FedRAMP requires that organization retain audit records for at least 90 days to provide supports for after-the-fact
investigations of security incidents and to meet regulatory and organizational information retention requirements.

NIST 800-53 AU-4 Audit Storage Capacity: Audit records for each of the Microsoft Azure services are captured by the
Monitoring Agents (MAs) and retained in Azure Storage. Each Storage account is allocated sufficient storage capacity for
the retention of at least 90 days’ worth of logs and is monitored for usage by the service component teams. If an account
is near capacity, service teams are notified by the Storage team and the appropriate component teams are then required
to create an additional storage account to expand the capacity. Before adding security-related events/logs, service teams
re-evaluate service Storage capacity because OS events and Internet Information Services (IIS) logs can be potentially
large. It is each service team’s responsibility to take care of capacity planning. Service teams must allocate a Storage
account.

NIST 800-53 AU-11 Audit Record Retention: Logs are retained in a central repository for at least 90 days to support
investigations of security incidents and to meet regulatory retention requirements.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 131

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 197 Covers NIST 800-53 AU-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 222 Covers NIST 800-53 AU-11

R4 Part 4.4

CIP-007-6 Table R4 – Security Event Monitoring

Part Applicable Systems Requirements Measures

4.4 High Impact BES Cyber Systems and Review a summarization or sampling Examples of evidence may include, but are
their associated: of logged events as determined by not limited to, documentation describing
1. EACMS; and the Responsible Entity at intervals no the review, any findings from the review (if
2. PCA greater than 15 calendar days to any), and dated documentation showing the
identify undetected Cyber Security review occurred.
Incidents.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity can generate summary reports based on logged events. Registered Entity is responsible for reviewing
and analyzing information system audit records for indications of inappropriate or unusual activity at the required
frequency. Azure does not inspect, approve, or monitor individual customer applications.

Cloud Provider Responsibility: No

NIST 800-53 AU-6 Audit Review, Analysis, and Reporting: Audit log review occurs at least weekly or can be triggered at
any time by a security incident, customer request or escalation, or any other incident impacting production functionality.
Audit records are reviewed and analyzed by the Security Incident Management (SIM) team for indications of inappropriate
or unusual activity, including the indications of compromise identified in SI-4(5), as mentioned in CIP-007-6 R4 Part 4.2
earlier in this section.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 132

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 203 Covers NIST 800-53 AU-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Supporting Evidence and Documentation

R5. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-007-6 Table R5 – System Access Controls. [Violation Risk Factor:
Medium] [Time Horizon: Operations Planning].
M5. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-007-6 Table 5 – System Access Controls and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R5 Part 5.1

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.1 High Impact BES Cyber Systems and Have a method(s) to enforce An example of evidence may include, but is
their associated: authentication of interactive user not limited to, documentation describing
1. EACMS; access, where technically feasible. how access is authenticated.
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. EACMS;
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for properly identifying and authenticating end users. For example, Registered Entity can
MICROSOFT CONFIDENTIAL – NDA REQUIRED 133
Cloud Implementation Guide for NERC Audits

use Active Directory Federation Services (ADFS) or the Azure Active Directory (AD) service for identity management.
Customers should review online documentation for Azure Active Directory.

Cloud Provider Responsibility: Yes

NIST 800-53 IA-2 Identification and Authentication (Organizational Users): Microsoft Azure personnel accessing the Azure
environment are uniquely identified by their Microsoft corporate Active Directory username and authenticated using
eAuth Level 4 and FIPS 140-2 compliant Gemalto smart cards or approved eAuth Level 4 and FIPS 140-2 compliant Trusted
Platform Modules (TPM). Active Directory strictly enforces unique identifiers.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 385 Covers NIST 800-53 IA-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.2

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.2 High Impact BES Cyber Systems and Identify and inventory all known An example of evidence may include, but is
their associated: enabled default or other generic not limited to, a listing of accounts by
1. EACMS; account types, either by system, by account types showing the enabled or
2. PACS; and groups of systems, by location, or by generic account types in use for the BES
3. PCA system type(s). Cyber System.
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for managing end user accounts. For example, Registered Entity can use Active Directory
Federation Services (ADFS) or the Azure Active Directory (AD) Service for account management. Customers should review
online documentation for Azure Active Directory, including Azure Identity Management and access control security best
practices. Registered Entity is responsible for changing default content of authenticators prior to deployment.

There are no local user accounts and groups on customer Azure PaaS Virtual Machines (VMs) and the default Windows
Administrator account is disabled. Remote access to customer PaaS VMs is not possible without first creating a local user
account and then initiating a Remote Desktop Protocol (RDP) session for access.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 134

Cloud Implementation Guide for NERC Audits

For Azure IaaS VMs, customers have full control over remote access. Customers have sole control over creating local
accounts to facilitate remote access via RDP. The default account is Administrator (the name can be changed by the
customer) and the customer has sole control over assigning the password that is known only to the customer. Customers
can also change the default port number for incoming RDP requests. Customers provision IaaS VMs from the Azure
Marketplace or bring their own VM images.

Cloud Provider Responsibility: Yes

NIST 800-53 IA-5 Authenticator Management: Default authentication credentials are often well known, easily
discoverable, and present a significant security risk. Therefore, they are changed upon installation. The local administrator
account is renamed and disabled. Default passwords are changed for the local admin account and root accounts for
network devices (including SNMP community strings).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 384 Covers NIST 800-53 IA-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.3

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.3 High Impact BES Cyber Systems and Identify individuals who have An example of evidence may include, but is
their associated: authorized access to shared not limited to, listing of shared accounts
1. EACMS; accounts. and the individuals who have authorized
2. PACS; and access to each shared account.
3. PCA
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for identifying end users who have authorized access to shared accounts. Registered Entity
can manage end user accounts via Active Directory Federation Services (ADFS) or the Azure Active Directory (AD) Service.
Customers should review online documentation for Azure Active Directory, including Azure Identity Management and

MICROSOFT CONFIDENTIAL – NDA REQUIRED 135

Cloud Implementation Guide for NERC Audits

access control security best practices.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-2(10) Account Management | Shared / Group Account Credential Termination: Microsoft Azure only
allows the use of shared or group accounts when those accounts are required for a clearly-defined administrative purpose
that cannot be fulfilled with individual accounts. The credentials for these accounts must be stored in one of the approved
Secret Stores, which tracks and monitors access to secrets. Account owners are required to rotate shared account
credentials at least every 70 days. Additionally, account owners are required to rotate shared account credentials
whenever an employee leaves the group.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 119-120 Covers NIST 800-53 AC-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.4

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.4 High Impact BES Cyber Systems and Change known default passwords, Examples of evidence may include, but are
their associated: per Cyber Asset capability not limited to:
1. EACMS; • Records of a procedure that
2. PACS; and passwords are changed when new
3. PCA devices are in production; or
Medium Impact BES Cyber Systems • Documentation in system manuals
or other vendor documents
and their associated:
1. EACMS; showing default vendor passwords
2. PACS; and were generated pseudo-randomly
3. PCA and are thereby unique to the
device.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for managing their authenticators, including changing default content of authenticators
prior to deployment.

Cloud Provider Responsibility: Yes

NIST 800-53 IA-5 Authenticator Management: At the time of initial account creation, Active Directory assigns a unique
identification and random temporary password which meets Microsoft Corporate policy requirements. The unique
identification associated with the account is maintained by Active Directory throughout the life of the account. Account
MICROSOFT CONFIDENTIAL – NDA REQUIRED 136
Cloud Implementation Guide for NERC Audits

identification is never repeated within Active Directory.

Default authentication credentials are often well known, easily discoverable, and present a significant security risk.
Therefore, they are changed upon installation. The local administrator account is renamed and disabled. Default
passwords are changed for the local admin account and root accounts for network devices (including SNMP community
strings).

Vendor supplied default passwords must be changed prior to use of associated application/service/system in Online
Services environments. Individual service owners are responsible for implementing policies and processes to change these
vendor-supplied defaults prior to service enablement.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 382, 384 Covers NIST 800-53 IA-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.5

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.5 High Impact BES Cyber Systems and For password-only authentication for Examples of evidence may include, but are
their associated: interactive user access, either not limited to:
1. EACMS; technically or procedurally enforce • System-generated reports or
2. PACS; and the following password parameters: screen-shots of the system-
3. PCA 5.5.1. Password length that is, at enforced password parameters,
least, the lesser of eight including length and complexity; or
Medium Impact BES Cyber Systems
and their associated:
characters or the maximum • Attestations that include a
length supported by the reference to the documented
1. EACMS;
Cyber Asset; and procedures that were followed.
2. PACS; and
5.5.2. Minimum password
3. PCA
complexity that is the lesser
of three or more different
types of characters (e.g.,
uppercase alphabetic,
lowercase alphabetic,
numeric, non-
alphanumeric) or the
maximum complexity
supported by the Cyber
Asset.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
MICROSOFT CONFIDENTIAL – NDA REQUIRED 137
Cloud Implementation Guide for NERC Audits

evidence, including links to the appropriate page, are recommended.

Registered Entity Responsibility: Yes
Registered Entity is responsible for enforcing password length and complexity for end users. For example, Registered
Entity can use on-premises Active Directory or Azure Active Directory for identity management, including enforcing
password length and complexity.

Cloud Provider Responsibility: Yes

Interactive remote access to Azure production systems is not possible via password-only authentication. Authorized Azure
personnel utilize Microsoft-issued information systems (Secure Access Workstation, SAW) and connect remotely to the
Azure cluster from CorpNet. Users are identified via two-factor authentication based on a unique Active Directory (AD)
identifier and password from the Corporate domain in combination with a smart card. SAWs are security devices that
provide users with privileged or elevated access to Azure production systems for platform troubleshooting and
maintenance. A SAW is designed to protect users from credential theft/misuse and malware attacks. SAWs are monitored
by Microsoft.

NIST 800-53 IA-5(1) Authenticator Management | Password-based Authentication: In accordance with C+AI Security
policy, Microsoft Azure and Azure Infrastructure enforce case-sensitive passwords with a minimum password length of 14
characters and at least one each of upper-case letters, lower-case letters, numbers, and special characters. Additional risk
mitigating measures are in place for access to Azure or Azure Government production systems in the form of mandatory
two-factor authentication and use of Microsoft issues Secure Access Workstations.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 386-387 Covers NIST 800-53 IA-5(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.6

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.6 High Impact BES Cyber Systems and Where technically feasible, for Examples of evidence may include, but are
their associated: password-only authentication for not limited to:
1. EACMS; interactive user access, either • System-generated reports or
2. PACS; and technically or procedurally enforce screen-shots of the system-
3. PCA password changes or an obligation enforced periodicity of changing
to change the password at least once passwords; or
Medium Impact BES Cyber Systems
every 15 calendar months. • Attestations that include a
with External Routable Connectivity
and their associated: reference to the documented
1. EACMS; procedures that were followed.
2. PACS; and
3. PCA

MICROSOFT CONFIDENTIAL – NDA REQUIRED 138

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for enforcing password changes for end users. For example, Registered Entity can use on-
premises Active Directory or Azure Active Directory for identity management, including enforcing password changes.
Customers should review documentation on password policies and restrictions in Azure Active Directory.

Cloud Provider Responsibility: Yes

NIST 800-53 IA-5 Authenticator Management: Authenticator requirements for domain accounts are the following:

• Enforce password history = 24 passwords remembered

• Maximum password age = 70 days
• Minimum password age = 1 day

These requirements are defined and managed by C+AI Security and enforced in Active Directory. Users must change
passwords every 70 days.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 384 Covers NIST 800-53 IA-5
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R5 Part 5.7

CIP-007-6 Table R5 – System Access Control

Part Applicable Systems Requirements Measures

5.7 High Impact BES Cyber Systems and Where technically feasible, either: Examples of evidence may include, but are
their associated: • Limit the number of not limited to:
1. EACMS; unsuccessful authentication • Documentation of the account-
2. PACS; and attempts; or lockout parameters; or
3. PCA • Generate alerts after a • Rules in the alerting configuration
Medium Impact BES Cyber Systems at threshold of unsuccessful showing how the system notified
Control Centers and their associated: authentication attempts. individuals after a determined
1. EACMS; number of unsuccessful login
attempts.
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
MICROSOFT CONFIDENTIAL – NDA REQUIRED 139
Cloud Implementation Guide for NERC Audits

evidence, including links to the appropriate page, are recommended.

Registered Entity Responsibility: Yes
Registered Entity is responsible for configuring unsuccessful login settings for its end users, e.g., enforcing a defined limit
of consecutive invalid login attempts during a defined time period, and generating alerts when the maximum number of
unsuccessful login attempts is exceeded. Customers should review documentation on password policies and restrictions
in Azure Active Directory.

Cloud Provider Responsibility: Yes

NIST 800-53 AC-7 Unsuccessful Logon Attempts: For all access to the Azure environment, Microsoft personnel must use
two-factor authentication through the use of a smart card and PIN. Smart card authentication enforces lockout after 5
failed login attempts. After five invalid access attempts within 15 minutes, a user’s smart card is locked out for at least 30
minutes, or until unlocked by an administrator.

Once a user is locked out after five (5) invalid access attempts, the user must either:

• Take action to unblock and reset the PIN using the PIN Unblock Tool. This will notify the user’s direct manager that a PIN
unblock was requested.
• Contact an administrator through the help desk to manually unblock and reset the PIN.

Azure has implemented compensating controls described below to alert security personnel to instances where brute force
password guessing is attempted, and apply additional authentication mechanisms to reduce the usefulness of an account
password acquired through brute force guessing (or any other method). These compensating controls meet the objective
of the original control and address additional risk.

• There are two entry points into the Azure Infrastructure. In each case, either an additional authentication factor (i.e. a
smartcard) or a completely separate user account must be used in order to gain access to the environment.
• For entry via the corporate network, a user must first successfully authenticate against one of the corporate domains.
• For connections directly to the Azure Infrastructure Server environment via un-trusted locations (primarily the internet),
in addition to user name and password combinations dual factor authentication (smartcard) is required.
• In addition to implementing these forms of dual or multi-factor authentication, an account password policy is enforced
for the domains including strong password complexity, password expiration, password history, and minimum password
length (refer to IA-05 for further details under CIP-007-6 R5.5).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 138-139 Covers NIST 800-53 AC-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 140

Cloud Implementation Guide for NERC Audits

CIP-008-5 – Cyber Security – Incident Reporting and Response Planning

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall document one or more Cyber Security Incident response plan(s) that collectively
include each of the applicable requirement parts in CIP-008-5 Table R1 – Cyber Security Incident Response Plan
Specifications. [Violation Risk Factor: Lower] [Time Horizon: Long Term Planning].
M1. Evidence must include each of the documented plan(s) that collectively include each of the applicable
requirement parts in CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications.

R1 Part 1.1

CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications

Part Applicable Systems Requirements Measures
An example of evidence may include, but is
1.1 High Impact BES Cyber Systems One or more processes to identify,
classify, and respond to Cyber not limited to, dated documentation of
Medium Impact BES Cyber Systems Cyber Security Incident response plan(s)
Security Incidents.
that include the process to identify,
classify, and respond to Cyber Security
Incidents.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for developing Incident Response (IR) plans for all controls applicable to assets deployed
in the cloud. For details on Azure security incident management procedures, customers should review Microsoft Azure
Security Response in the Cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-4 Incident Handling: Microsoft Azure has implemented the incident handling control by creating a
standardized incident handling model. This framework is derived from multiple incident handling methodologies including
NIST SP 800-61 R2 Computer Security Incident Handling Guide, ISO/IEC 27035:2011 standard for Information Security
Incident Management, and the SANS institute publication “Computer Security Incident Handling”.

The Microsoft Azure Incident Management process includes multiple stages throughout the resolution of an incident.
Incidents may be managed with the Crisis Management or Security Breach Incident sub-processes of the Incident
Management process. When incidents become triaged as a high severity event (Severity 2 or higher, Severity 0 being the
highest) they are managed with the Crisis Management sub-process. The incident management process for incident
handling includes steps for preparation, detection and analysis, containment, eradication, and recovery and post-incident
activity.

NIST 800-53 IR-8 Incident Response Plan: Microsoft Azure has developed and implemented the Microsoft Azure Incident
Management Standard Operating Procedure (SOP). The SOP provides a high-level approach for how the incident response
capability fits into the overall organization and describes the structure and organization of the incident response
capabilities. The incident response SOP does the following:

MICROSOFT CONFIDENTIAL – NDA REQUIRED 141

Cloud Implementation Guide for NERC Audits

• Describes the end-to-end process of security incident response, and how it is executed across the various functional
groups within Microsoft.
• Defines a methodical approach that may be applied to resolve security incidents and escalate incidents to the proper
internal authorities.

The SOP provides guidance for classifying the incidents and assigning severity. It also provides the characteristics that
could be associated with incidents to help categorize the incidents.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 414 Covers NIST 800-53 IR-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 435 Covers NIST 800-53 IR-8
Incident Management Incident Management 2018.01 8/23/2018 1-42 CIP-008-5 R1.1
SOP 2018.01.docx SOP

R1 Part 1.2

CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications

Part Applicable Systems Requirements Measures

1.2 High Impact BES Cyber Systems One or more processes to determine Examples of evidence may include, but are
if an identified Cyber Security not limited to, dated documentation of
Medium Impact BES Cyber Systems
Incident is a Reportable Cyber Cyber Security Incident response plan(s)
Security Incident and notify the that provide guidance or thresholds for
Electricity Sector Information determining which Cyber Security Incidents
Sharing and Analysis Center (ES- are also Reportable Cyber Security Incidents
ISAC), unless prohibited by law. and documentation of initial notices to the
Initial notification to the ES-ISAC, Electricity Sector Information Sharing and
which may be only a preliminary Analysis Center (ES-ISAC).
notice, shall not exceed one hour
from the determination of a
Reportable Cyber Security Incident.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for developing a process to determine if a security incident is reportable, as well as
notifying relevant authorities. Registered Entity is also responsible for providing accurate and current contact information
to Microsoft in order to receive notifications of security incidents involving the potential breach of customer data.
Specifically, Registered Entity should inform Microsoft of the individuals, teams, and email addresses to be notified and
kept updated for the incident handling process. Upon a confirmed security incident, Azure Security Response will notify
MICROSOFT CONFIDENTIAL – NDA REQUIRED 142
Cloud Implementation Guide for NERC Audits

the subscription Administrators and Co-Administrators. Registered Entity should notify relevant authorities if a breach
occurs entirely within the Registered Entity’s scope of responsibility, e.g., if a customer Virtual Machine (VM) is breached
due to a poor password.

Cloud Provider Responsibility: Yes

Azure Incident Management SOP describes a process used by Microsoft to determine if an incident is reportable (see
Section 4.2.2. Escalation and Notification).

The Assess stage begins when an Incident Engineer acknowledges ownership of an event and ends when an event has
been classified using a Classify, Escalate, Notify (CEN) and assigned the appropriate severity in the Ticket. The severity can
change throughout the troubleshooting process as more information becomes available. Incident Engineers leverage
application monitoring and instrumentation to validate impact before severity assignment occurs.

The Escalation and Notification phase begins in the Assess stage as soon as severity assignment occurs. The CEN defines
the escalation and notification requirements for each severity level. The first escalation point is the Incident Manager.
Notification will continue throughout the remaining phases of the process. During this phase, the Security Incident
Manager completes the following tasks:

1. Make the final determination whether an event impacts system or data security.
2. Mobilize additional security response and investigation personnel.
3. Alert Communications, CELA, privacy team or additional LiveSite personnel as necessary.
4. Decide in coordination with CELA whether to begin execution of the Security Incident Notification Sub-Process.
5. Engage a Crisis Manager if warranted by the significance of the issue (as defined by the CEN)

NIST 800-53 IR-6 Incident Reporting: The Azure Security team will notify the appropriate contacts (FedRAMP, customer,
and the United States Computer Emergency Readiness Team US-CERT) of an incident, incident updates, and resolution.
Azure reports security incidents involving customer data per the timelines and process documented in the Microsoft Azure
FedRAMP Incident Response Plan.

• Reporting to US-CERT
The Azure Information System Security Officer (ISSO) will make the report using the US-CERT Incident Reporting System
interface or through the US-CERT report form and based on federal incident reporting guidelines to report incidents within
the time periods defined in the Azure FedRAMP Incident Response Plan.

• Reporting to Customers
Customers will receive notification of security incidents involving the confirmed breach of their customer data in email
sent by the ISSO, through updates to the Service Health Dashboard, or the customer’s Microsoft Azure Management Portal
within the time periods defined in the Microsoft Azure FedRAMP Incident Response Plan.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 423 Covers NIST 800-53 IR-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 143

Cloud Implementation Guide for NERC Audits

Incident Management Incident Management 2018.01 8/23/2018 16 CIP-008-5 R1.2

SOP 2018.01.docx SOP

R1 Part 1.3

CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications

Part Applicable Systems Requirements Measures
An example of evidence may include, but is
1.3 High Impact BES Cyber Systems The roles and responsibilities of
Cyber Security Incident response not limited to, dated Cyber Security
Medium Impact BES Cyber Systems Incident response process(es) or
groups or individuals.
procedure(s) that define roles and
responsibilities (e.g., monitoring, reporting,
initiating, documenting, etc.) of Cyber
Security Incident response groups or
individuals.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for defining roles and responsibilities as part of its incident response plan.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-8 Incident Response Plan: Microsoft Azure has developed and implemented the Microsoft Azure Incident
Management Standard Operating Procedure (SOP). The SOP explains the different phases of the incident response
lifecycle. It also identifies the internal partners, cross team contacts, roles and responsibilities, and lists the individuals and
management support needed to effectively maintain the incident response capability.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 435 Covers NIST 800-53 IR-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Incident Management Incident Management 2018.01 8/23/2018 8-11 CIP-008-5 R1.2
SOP 2018.01.docx SOP

MICROSOFT CONFIDENTIAL – NDA REQUIRED 144

Cloud Implementation Guide for NERC Audits

R1 Part 1.4

CIP-008-5 Table R1 – Cyber Security Incident Response Plan Specifications

Part Applicable Systems Requirements Measures
An example of evidence may include, but is
1.4 High Impact BES Cyber Systems Incident handling procedures for
Cyber Security Incidents. not limited to, dated Cyber Security
Medium Impact BES Cyber Systems Incident response process(es) or
procedure(s) that address incident handling
(e.g., containment, eradication,
recovery/incident resolution).

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for developing incident handling procedures for all controls applicable to assets deployed
in the cloud. For details on Azure security incident management procedures, customers should review Microsoft Azure
Security Response in the Cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-4 Incident Handling: Microsoft Azure has implemented the incident handling control by creating a
standardized incident handling model. This framework is derived from multiple incident handling methodologies including
NIST SP 800-61 R2 Computer Security Incident Handling Guide, ISO/IEC 27035:2011 standard for Information Security
Incident Management, and the SANS institute publication “Computer Security Incident Handling”.

The incident management stage overview is provided below:

# Phase Description
1 Detect Origination of an event
2 Assess To assess the event, a small team performs preliminary analysis, data classification and
determines if the issue needs to be diagnosed.
3 Diagnose To understand the potential impact, severity and classification, the team determines and
secures expertise needed. At any time during diagnosis, if the issue is deemed a potential
security incident, the team establishes response priorities and reviews roles and
responsibilities and initiates notification protocols. If the issue is deemed to be a potential
security breach incident, the incident is managed with the Security Breach Response sub-
process.
4 Stabilize and recover To stabilize the situation for customer-impacting incidents, the Communications Manager
releases internal and external communications and status updates until the issue is
resolved. The Technical Team conducts technical investigation, identifies containment,
mitigations and workaround strategies and implements the recovery strategy.
5 Close For all Customer-impacting, Security Breach and Emergency Incidents, the internal parties
involved in the incident response will conduct a Post Incident Response to identify
technical lapses, procedural failures, manual errors, process flaws and communication
glitches that might have caused the incident or that were identified during the response.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 145

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 414-415 Covers NIST 800-53 IR-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement each of its documented Cyber Security Incident response plans to
collectively include each of the applicable requirement parts in CIP-008-5 Table R2 – Cyber Security Incident
Response Plan Implementation and Testing. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning
and Real-Time Operations].
M2. Evidence must include, but is not limited to, documentation that collectively demonstrates implementation of
each of the applicable requirement parts in CIP-008-5 Table R2 – Cyber Security Incident Response Plan
Implementation and Testing.

R2 Part 2.1

CIP-008-5 Table R2 – Cyber Security Incident Response Plan Implementation and Testing
Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems Test each Cyber Security Incident Examples of evidence may include, but are
response plan(s) at least once every not limited to, dated evidence of a lessons-
Medium Impact BES Cyber Systems
15 calendar months: learned report that includes a summary of
• By responding to an actual the test or a compilation of notes, logs, and
Reportable Cyber Security communication resulting from the test.
Incident; Types of exercises may include discussion or
• With a paper drill or operations based exercises.
tabletop exercise of a
Reportable Cyber Security
Incident; or
• With an operational
exercise of a Reportable
Cyber Security Incident.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for testing its cyber security incident response plan at least once every 15 months. For
details on Azure security incident management procedures, customers should review Microsoft Azure Security Response
in the Cloud.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 146

Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: Yes

NIST 800-53 IR-3 Incident Response Testing: Microsoft Azure C+AI Security Operations Center (SOC) tests incident
response methodology and tools to ensure optimal performance during incidents in the Azure Infrastructure environment
on at least an annual basis. C+AI SOC testing occurs in both test environments as well as production environments. A
quarterly comprehensive production exercise is conducted to validate the effectiveness of C+AI SOC capability in a live fire
exercise. All results are documented in the C+AI SOC Incident Response Test Plan.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 410 Covers NIST 800-53 IR-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.2

CIP-008-5 Table R2 – Cyber Security Incident Response Plan Implementation and Testing
Part Applicable Systems Requirements Measures

2.2 High Impact BES Cyber Systems Use the Cyber Security Incident Examples of evidence may include, but are
response plan(s) under Requirement not limited to, incident reports, logs, and
Medium Impact BES Cyber Systems
R1 when responding to a Reportable notes that were kept during the incident
Cyber Security Incident or response process, and follow-up
performing an exercise of a documentation that describes deviations
Reportable Cyber Security Incident. taken from the plan during the incident or
Document deviations from the exercise.
plan(s) taken during the response to
the incident or exercise.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for documenting any deviations from the incident response plan.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-3 Incident Response Testing: The C+AI Security Operations Center (SOC) team conducts incident response
testing and exercises per protocols and procedures identified in the Security Incident Handling SOP. This document
leverages the NIST SP 800-61 R2 Computer Security Incident Handling Guide to create a compliant incident response
handling program. The C+AI SOC team tests and exercises in accordance with NIST SP 800-61 R2.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 147

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 410 Covers NIST 800-53 IR-3
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.3

CIP-008-5 Table R2 – Cyber Security Incident Response Plan Implementation and Testing
Part Applicable Systems Requirements Measures

2.3 High Impact BES Cyber Systems Retain records related to Reportable An example of evidence may include, but is
Cyber Security Incidents. not limited to, dated documentation, such
Medium Impact BES Cyber Systems
as security logs, police reports, emails,
response forms or checklists, forensic
analysis results, restoration records, and
post-incident review notes related to
Reportable Cyber Security Incidents.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for retaining records related to reportable cyber security incidents.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-8 Incident Response Plan: A formal Incident Report is produced by the service teams and augmented with
the Azure Security Incident Management team’s additions. These reports, which include lessons learned, are created for
all events with a Severity 1 rating. For incidents of lesser severity, if there are significant lessons learned that have general
applicability across the Azure environment, an incident report is created. The incident reports are maintained by Azure
Security Incident Response or by the impacted service team and are provided to the relevant stakeholders for review.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 435 Covers NIST 800-53 IR-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 148

Cloud Implementation Guide for NERC Audits

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall maintain each of its Cyber Security Incident response plans according to each of
the applicable requirement parts in CIP-008-5 Table R3 – Cyber Security Incident Response Plan Review, Update,
and Communication. [Violation Risk Factor: Lower] [Time Horizon: Operations Assessment].
M3. Evidence must include, but is not limited to, documentation that collectively demonstrates maintenance of each
Cyber Security Incident response plan according to the applicable requirement parts in CIP-008-5 Table R3 –
Cyber Security Incident.

R3 Part 3.1

CIP-008-5 Table R3 – Cyber Security Incident Response Plan

Review, Update, and Communication
Part Applicable Systems Requirements Measures

3.1 High Impact BES Cyber Systems No later than 90 calendar days after An example of evidence may include, but is
completion of a Cyber Security not limited to, all of the following:
Medium Impact BES Cyber Systems
Incident response plan(s) test or 4. Dated documentation of post
actual Reportable Cyber Security incident(s) review meeting notes or
Incident response: follow-up report showing lessons
3.2.1. Document any lessons learned associated with the Cyber
learned or document the Security Incident response plan(s) test
absence of any lessons or actual Reportable Cyber Security
learned; Incident response or dated
3.2.2. Update the Cyber Security documentation stating there were no
Incident response plan lessons learned;
based on any 5. Dated and revised Cyber Security
documented lessons Incident response plan showing any
learned associated with changes based on the lessons
the plan; and learned; and
3.2.3. Notify each person or 6. Evidence of plan update distribution
group with a defined role including, but not limited to:
in the Cyber Security • Emails;
Incident response plan of • USPS or other mail service;
the updates to the Cyber • Electronic distribution system;
Security Incident or
response plan based on • Training sign-in sheets.
any documented lessons
learned.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for documenting lessons learned no later than 90 days following the completion of an
incident response test or actual reportable incident response.

Cloud Provider Responsibility: Yes

NIST 800-53 IR-8 Incident Response Plan: On a monthly basis, all impacting incidents for the previous month are reviewed
with the leadership/executive team. Impact and resolution of the incident and changes to the Incident Response plan are
MICROSOFT CONFIDENTIAL – NDA REQUIRED 149
Cloud Implementation Guide for NERC Audits

covered. The Incident Response plan is revised to address system/organizational changes or problems encountered during
plan implementation, execution, or testing.

After changes have been made to the Microsoft Azure Incident Response Plan, it is made available for review to the
incident response personnel as identified by role in the Microsoft Azure Incident Response Plan via a centralized
SharePoint site.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 440-441 Covers NIST 800-53 IR-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R3 Part 3.2

CIP-008-5 Table R3 – Cyber Security Incident Response Plan

Review, Update, and Communication
Part Applicable Systems Requirements Measures

3.2 High Impact BES Cyber Systems No later than 60 calendar days after An example of evidence may include, but is
a change to the roles or not limited to:
Medium Impact BES Cyber Systems
responsibilities, Cyber Security 3. Dated and revised Cyber Security
Incident response groups or Incident response plan with changes
individuals, or technology that the to the roles or responsibilities,
Responsible Entity determines would responders or technology; and
impact the ability to execute the 4. Evidence of plan update distribution
plan: including, but not limited to:
3.2.1. Update the Cyber Security • Emails;
Incident response plan(s); • USPS or other mail service;
and • Electronic distribution system;
3.2.2. Notify each person or or
group with a defined role • Training sign-in sheets.
in the Cyber Security
Incident response plan of
the updates.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for updating the incident response plan and notifying each group and person with a
defined role in the incident response plan no later than 60 days after a change to the roles and responsibilities, incident
response groups or individuals, or technology that impacts the ability to execute the plan.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 150

Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: Yes

NIST 800-53 IR-8 Incident Response Plan: After changes have been made to the Microsoft Azure Incident Response plan,
it is made available for review to the incident response personnel as identified by role in the Microsoft Azure Incident
Response plan via a centralized SharePoint site. All Microsoft Azure incident response procedures are documented in the
Microsoft Azure Incident Response plan.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 441 Covers NIST 800-53 IR-8
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 151

Cloud Implementation Guide for NERC Audits

CIP-009-6 – Cyber Security – Recovery Plans for BES Cyber Systems

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall have one or more documented recovery plans that collectively include each of the
applicable requirement parts in CIP-009-6 Table R1 – Recovery Plan Specifications. [Violation Risk Factor:
Medium] [Time Horizon: Long Term Planning].
M1. Evidence must include the documented recovery plan(s) that collectively include the applicable requirement
parts in CIP-009-6 Table R1 – Recovery Plan Specifications.

R1 Part 1.1
CIP-009-6 Table R1 – Recovery Plan Specifications
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and Conditions for activation of the An example of evidence may include, but is
1.1
their associated: recovery plan(s). not limited to, one or more plans that
1. EACMS; and include language identifying conditions for
2. PACS activation of the recovery plan(s).

Medium Impact BES Cyber Systems

and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for developing contingency plans for all controls applicable to its assets deployed in the
cloud. Customers should review Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-2 Contingency Plan: Microsoft is responsible for meeting the contingency planning requirements for all
Azure services consumed by customer applications.

The Microsoft Azure Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) provides the detailed processes for
contingency planning for Microsoft Azure. This document identifies essential missions and business functions and
associated contingency requirements. It serves as a guide for Microsoft Azure to respond, recover and resume operations
during a serious adverse event. The BCP covers the key personnel, resources, services and actions required to continue
critical business processes and operations. This plan is intended to address extended business disruptions. The
development of the BCP follows Microsoft’s Enterprise Business Continuity Management (EBCM) implementation
standards.

The DRP covers the key personnel, resources, services and actions required to continue critical technology processes and
operations. This plan is intended to address extended service disruptions. The development of the DRP follows Microsoft’s
EBCM implementation standards.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 152

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 328 Covers NIST 800-53 CP-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Business Continuity Business Continuity 2018.02 11/5/2018 1-27 CIP-009-6 R1.1
and Disaster Recovery and Disaster Recover
(AZURE) 2018.02.docx SOP

R1 Part 1.2
CIP-009-6 Table R1 – Recovery Plan Specifications
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and Roles and responsibilities of An example of evidence may include, but is
1.2
their associated: responders. not limited to, one or more recovery plans
1. EACMS; and that include language identifying the roles
2. PACS and responsibilities of responders.

Medium Impact BES Cyber Systems

and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for identifying roles and responsibilities in its recovery plan specifications.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-2 Contingency Plan: The Microsoft Azure Business Continuity Plan (BCP) addresses this requirement in
Section 4: Roles, Responsibilities, Contacts, and Competence.

The BCP covers the key personnel, resources, services and actions required to continue critical business processes and
operations. This plan is intended to address extended business disruptions.

The DRP covers the key personnel, resources, services and actions required to continue critical technology processes and
operations. This plan is intended to address extended service disruptions.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 153

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 328 Covers NIST 800-53 CP-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Business Continuity Business Continuity 2018.02 11/5/2018 16-17 CIP-009-6 R1.1
and Disaster Recovery and Disaster Recover
(AZURE) 2018.02.docx SOP

R1 Part 1.3
CIP-009-6 Table R1 – Recovery Plan Specifications
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and One or more processes for the An example of evidence may include, but is
1.3
their associated: backup and storage of information not limited to, documentation of specific
1. EACMS; and required to recover BES Cyber processes for the backup and storage of
2. PACS System functionality. information required to recover BES Cyber
System functionality.
Medium Impact BES Cyber Systems
and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing processes for the storage and backup of data required to recover their
assets deployed in the cloud. Customers should review Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-9 Information System Backup: Azure Storage maintains three copies of customer data across separate
fault domains in the primary region using synchronous replication. Customers can also enable geo-redundant storage,
which maintains three additional copies of customer data also across separate fault domains in the paired region using
asynchronous replication. At any given time, Azure Storage provides 6 healthy replicas of customer data kept in two paired
regions that are located at least 400 miles apart.

For user level information stored in Azure SQL DB, data is replicated synchronously across three SQL Database storage
nodes within a region. This data is also automatically geo-replicated to the alternative storage site in a different geographic
region. If the datacenter hosting the customer data fails, the customers can utilize the Microsoft Azure Management Portal
or programmatic API to restore their data from the geo-replicated backup to any geographic region of their choice.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 154

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 353 Covers NIST 800-53 CP-9
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.4
CIP-009-6 Table R1 – Recovery Plan Specifications
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and One or more processes to verify the An example of evidence may include, but is
1.4
their associated: successful completion of the backup not limited to, logs, workflow or other
1. EACMS; and processes in Part 1.3 and to address documentation confirming that the backup
2. PACS any backup failures. process completed successfully and backup
failures, if any, were addressed.
Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing processes for the storage and backup of data required to recover their
assets deployed in the cloud. Customers should review Azure documentation on availability and resiliency.

NIST 800-53 CP-9(1) Information System Backup | Testing for Reliability / Integrity: Azure monitors all backups of the
system OS and the customer image(s) on a monthly or continuous basis using system generated alerts which notify Azure
operations team of any failed or incomplete backups. If a backup continuously fails, Azure will create an Incident
Management (ICM) incident to track and resolve the issue. In addition to system-generated alerts, restoration tests of
customer-requested restores are performed using the BCDR Manager tool. The integrity of data is automatically confirmed
upon completion of the backup. The restoration tests are captured and stored in BCDR Manager in order to generate
reports and perform root-cause analysis, as needed.

At any one time, Azure SQL DB keeps multiple replicas of data running: one primary replica and two secondary replicas.
Microsoft Azure SQL DB uses a quorum-based commit scheme where data is written to the primary and one of the
secondary replicas before the transaction is considered committed. If the hardware fails on the primary replica, Azure SQL
DB detects the failure and fails over to a secondary replica. In case of a physical loss of a replica, Azure SQL DB creates a
new replica automatically. Therefore, there are at least two physical transaction-consistent copies of customer images in
the datacenter at all times. Azure SQL DB will not write transactions to the database unless primary and secondary replicas
are made.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 155

Cloud Implementation Guide for NERC Audits

Additionally, Azure SQL DB utilizes warm backup site technology, as well as replication of the Azure SQL DB code, for the
Azure SQL DB service. Information within the system is therefore continuously replicated to the Azure Infrastructure
datacenters, eliminating the need for physical backup tapes.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 357-358 Covers NIST 800-53 CP-9(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.5
CIP-009-6 Table R1 – Recovery Plan Specifications
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and One or more processes to preserve An example of evidence may include, but is
1.5
their associated: data, per Cyber Asset capability, for not limited to, procedures to preserve data,
1. EACMS; and determining the cause of a Cyber such as preserving a corrupted drive or
2. PACS Security Incident that triggers making a data mirror of the system before
activation of the recovery plan(s). proceeding with recovery.
Medium Impact BES Cyber Systems Data preservation should not
and their associated: impede or restrict recovery.
1. EACMS; and
2. PACS

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing a process to preserve data needed to determine the cause of cyber
security incident that triggers recovery plan activation.

Cloud Provider Responsibility: Yes

NIST 800-53 AU-9 Protection of Audit Information: Azure implements protection of audit information through the use of
an authenticated and encrypted connection from the node to the centralized audit collection system Geneva Monitoring.
Access to the centralized audit collection systems is restricted to the Security Engineering and Operations groups based
on the standard access groups defined for Azure. As a result, only authorized personnel are allowed access to audit records
and their assigned rights prohibit them from modifying or deleting audit information.

NIST 800-53 CP-9 Information System Backup: The DPS policies and procedures describe the Data Protection Services
(DPS) roles, responsibilities, and services. It also describes in detail the backup standards, retention policies, monitoring,
and reports available to customers.

All disks are maintained under security of the various datacenters. All disks are stored within the datacenter if recyclable,

MICROSOFT CONFIDENTIAL – NDA REQUIRED 156

Cloud Implementation Guide for NERC Audits

or recalled for recovery, and are tracked on backup software by the disk number. Facilities are responsible for maintaining
the security of the disks while stored within the datacenter.

Backup disks are moved to an off-site facility for long term storage. The scalar (disk backup library), encryption device and
servers are located in the datacenter. Facility security monitors access to media (disks) and the disk scalars. All disks are
placed in off-site containers and locked for off-site transport to the secure storage facility. Disks are stored in open racks
and can be recalled by a single disk.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 217 Covers NIST 800-53 AU-9
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 353-354 Covers NIST 800-53 CP-10

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement its documented recovery plan(s) to collectively include each of the
applicable requirement parts in CIP-009-6 Table R2 – Recovery Plan Implementation and Testing. [Violation Risk
Factor: Lower] [Time Horizon: Operations Planning and Real-time Operations.]
M2. Evidence must include, but is not limited to, documentation that collectively demonstrates implementation of
each of the applicable requirement parts in CIP-009-6 Table R2 – Recovery Plan Implementation and Testing.

R2 Part 2.1
CIP-009-6 Table R2 – Recovery Plan Implementation and Testing
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and Test each of the recovery plans An example of evidence may include, but is
2.1
their associated: referenced in Requirement R1 at not limited to, dated evidence of a test (by
1. EACMS; and least once every 15 calendar recovering from an actual incident, with a
2. PACS months: paper drill or tabletop exercise, or with an
• By recovering from an operational exercise) of the recovery plan at
Medium Impact BES Cyber Systems at actual incident; least once every 15 calendar months. For
Control Centers and their associated: • With a paper drill or the paper drill or full operational exercise,
1. EACMS; and tabletop exercise; or evidence may include meeting notices,
2. PACS • With an operational minutes, or other records of exercise
exercise. findings.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes

MICROSOFT CONFIDENTIAL – NDA REQUIRED 157

Cloud Implementation Guide for NERC Audits

Registered Entity is responsible for testing its recovery plans at least once every 15 months. Customers should review
Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-4 Contingency Plan Testing: The Business Continuity Plan (BCP) Team schedules end-to-end recovery tests,
drives execution of the tests, identifies recovery gaps, and communicates test results. At least one major end-to-end
scenario is tested annually. In addition, each component team performs tests to exercise their scenario(s) listed in the
Azure Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) annually. These include every component and
critical process listed in the Azure BCP and DRP. Also, functional exercises are completed in real-time on an ongoing basis
as incidents occur. All systems that are tested are classified as high impact systems.

As stated in the Microsoft Enterprise Business Continuity (EBCM) Disaster Recovery (DR) Standard, Disaster Recovery
Plans (DRPs) cannot be considered reliable nor can a “critical for recovery” technology/system be considered capable of
recovery until DRPs have been validated. Validating develops teamwork, competency, confidence, and knowledge and
must include those who may be required to execute the procedures.

The purpose of the DR validation is to assess the effectiveness and usability of DRPs. It also provides validation of Recovery
Time Capability (RTC) and Recovery Point Capability (RPC), that Microsoft Security Policy guidelines are not compromised
and identifies areas for improvement by uncovering gaps in processes or procedures.

DR validations must be realistic and carefully planned so there is minimal risk of disruption to business operations or an
incident occurring as a direct result of the DR validation. DRPs must be validated within 12 months of the previous
validation date or anytime there is a significant change in personnel, technology/system, or procedures

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 337 Covers NIST 800-53 CP-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
FY18 Enterprise Enterprise Business 6.1 1/8/2018 8 CIP-009-6 R2.1
Disaster Recovery Continuity
Standard_FINAL 1-1- Management (EBCM)
2018.pdf DR Standard

MICROSOFT CONFIDENTIAL – NDA REQUIRED 158

Cloud Implementation Guide for NERC Audits

R2 Part 2.2
CIP-009-6 Table R2 – Recovery Plan Implementation and Testing
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and Test a representative sample of
2.2 An example of evidence may include, but is
their associated: information used to recover BES
not limited to, operational logs or test
1. EACMS; and Cyber System functionality at least
results with criteria for testing the usability
2. PACS once every 15 calendar months to
(e.g. sample tape load, browsing tape
ensure that the information is
contents) and compatibility with current
Medium Impact BES Cyber Systems at useable and is compatible with
system configurations (e.g. manual or
Control Centers and their associated: current configurations.
automated comparison checkpoints
1. EACMS; and
between backup media contents and
2. PACS An actual recovery that incorporates
current configuration).
the information used to recover BES
Cyber System functionality
substitutes for this test.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for testing its recovery plans at least once every 15 months. Customers should review
Azure documentation on availability and resiliency.

Cloud Provider Responsibility: No

FedRAMP requires that contingency plans be tested at least annually for moderate impact systems. Registered Entity is
responsible for testing a representative sample of information used to recover BES Cyber System functionality. Microsoft
does not approve or monitor customer applications and cannot conduct a recovery test that is specific to customer
application.

NIST 800-53 CP-4 Contingency Plan Testing: Testing reports are created for all tests, reviewed by the BCP team, and
entered into the BCDR Manager database. The BCP Team ensures that testing happens as per the defined schedule.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 337 Covers NIST 800-53 CP-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 159

Cloud Implementation Guide for NERC Audits

R2 Part 2.3
CIP-009-6 Table R2 – Recovery Plan Implementation and Testing
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems Test each of the recovery plans
2.3 Examples of evidence may include, but are
referenced in Requirement R1 at
not limited to, dated documentation of:
least once every 36 calendar months
through an operational exercise of • An operational exercise at least once
the recovery plans in an every 36 calendar months between
environment representative of the exercises, that demonstrates recovery
production environment. in a representative environment; or
• An actual recovery response that
An actual recovery response may
occurred within the 36 calendar month
substitute for an operational
timeframe that exercised the recovery
exercise.
plans.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for testing its recovery plans at least once every 15 months. Customers should review
Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

FedRAMP requires that contingency plans be tested at least annually for moderate impact systems.

NIST 800-53 CP-4 Contingency Plan Testing: The Business Continuity Plan (BCP) Team schedules end-to-end recovery tests,
drives execution of the tests, identifies recovery gaps, and communicates test results. At least one major end-to-end
scenario is tested annually. In addition, each component team performs tests to exercise their scenario(s) listed in the
Azure Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) annually. These include every component and
critical process listed in the Azure BCP and DRP. Also, functional exercises are completed in real-time on an ongoing basis
as incidents occur. All systems that are tested are classified as high impact systems.

As stated in the Microsoft Enterprise Business Continuity (EBCM) Disaster Recovery (DR) Standard, Disaster Recovery
Plans (DRPs) cannot be considered reliable nor can a “critical for recovery” technology/system be considered capable of
recovery until DRPs have been validated. Validating develops teamwork, competency, confidence, and knowledge and
must include those who may be required to execute the procedures.

The purpose of the DR validation is to assess the effectiveness and usability of DRPs. It also provides validation of Recovery
Time Capability (RTC) and Recovery Point Capability (RPC), that Microsoft Security Policy guidelines are not compromised
and identifies areas for improvement by uncovering gaps in processes or procedures.

DR validations must be realistic and carefully planned so there is minimal risk of disruption to business operations or an
incident occurring as a direct result of the DR validation. DRPs must be validated within 12 months of the previous
validation date or anytime there is a significant change in personnel, technology/system, or procedures

MICROSOFT CONFIDENTIAL – NDA REQUIRED 160

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 337 Covers NIST 800-53 CP-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
FY18 Enterprise Enterprise Business 6.1 1/8/2018 8 CIP-009-6 R2.3
Disaster Recovery Continuity
Standard_FINAL 1-1- Management (EBCM)
2018.pdf DR Standard

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall maintain each of its recovery plan(s) in accordance with each of the applicable
requirement parts in CIP-009-6 Table R3 – Recovery Plan Review, Update and Communication. [Violation Risk
Factor: Lower] [Time Horizon: Operations Assessment].
M3. Acceptable evidence includes, but is not limited to, each of the applicable requirement parts in CIP-009-6 Table
R3 – Recovery Plan Review, Update and Communication.

R3 Part 3.1
CIP-009-6 Table R3 – Recovery Plan Review, Update and Communication
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and
3.1 No later than 90 calendar days after An example of evidence may include, but is
their associated:
completion of a recovery plan test or not limited to, all of the following:
1. EACMS; and
actual recovery:
2. PACS 4. Dated documentation of identified
3.1.1. Document any lessons
deficiencies or lessons learned for
learned associated with a
Medium Impact BES Cyber Systems at each recovery plan test or actual
recovery plan test or actual
Control Centers and their associated: incident recovery or dated
recovery or document the
1. EACMS; and documentation stating there were no
absence of any lessons
2. PACS lessons learned;
learned;
3.1.2. Update the recovery plan 5. Dated and revised recovery plan
based on any documented showing any changes based on the
lessons learned associated lessons learned; and
with the plan; and
6. Evidence of plan update distribution
3.1.3. Notify each person or
including, but not limited to:
group with a defined role in
the recovery plan of the • Emails;
updates to the recovery
• USPS or other mail service;
plan based on any
documented lessons • Electronic distribution system; or
learned.
• Training sign-in sheets.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 161

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for documenting lessons learned from recovery plan tests, updating the recovery plan
based on lessons learned, and communicating recovery plan updates to all relevant stakeholders. Customers should
review Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-4 Contingency Plan Testing: As a result of the testing performed, the Business Continuity Plan (BCP) Team,
in conjunction with the service teams, reviews supporting evidence documented in Team Foundation Services (TFS) and
identifies improvement opportunities for short, medium, and long-term follow-up. If critical issues are identified during
an exercise, they are worked on until resolution, and contingency plans get updated accordingly as needed. The overall
readiness of the Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) includes the readiness to execute the
plan per the test results.

As stated in the Business Continuity and Disaster Recover SOP, the BCP and DRP documents are reviewed on annual basis
or when required to address changes to the organization, information system, or environment of operation and problems
encountered during plan implementation, execution, or testing. This review and revision ensure that the information
included in the documents is accurate and up-to-date. Evidence of review is captured in the version history section of the
documents. In addition, the BCP and DRP documents are updated after major releases or updates. Whenever there are
major changes to the BCP document, the BPD also communicates the updated document to the key personnel involved in
the BCP process. The BCP is distributed in hardcopy to the Microsoft Azure NOC and is available on the Microsoft Azure
Business Continuity SharePoint site. The Microsoft Azure Operations Managers alias is notified when changes are made.
This alias includes all core personnel responsible for leading the platform recovery.

As stated in the Microsoft Enterprise Business Continuity Management (EBCM) Disaster Recovery (DR) Standard, within
14 days of completing a DR validation – planned or real outage - the recovery team must review the validation activities
and document a list of action items for remediation / improvements in an After Action Review (AAR) report. Issues
uncovered should be included as action items with owners assigned, along with scope, objectives, outcome, and mitigation
timelines; however, all action items in the AAR do not have to be finalized within the 14 days.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 337 Covers NIST 800-53 CP-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Business Continuity Business Continuity 2018.02 11/5/2018 21 CIP-009-6 R3.1
and Disaster Recovery and Disaster Recover
(AZURE) 2018.02.docx SOP
FY18 Enterprise Enterprise Business 6.1 1/8/2018 12 CIP-009-6 R3.1
Disaster Recovery Continuity

MICROSOFT CONFIDENTIAL – NDA REQUIRED 162

Cloud Implementation Guide for NERC Audits

Standard_FINAL 1-1- Management (EBCM)

2018.pdf DR Standard

R3 Part 3.2
CIP-009-6 Table R3 – Recovery Plan Review, Update and Communication
Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems and
3.2 No later than 60 calendar days after An example of evidence may include, but is
their associated:
a change to the roles or not limited to, all of the following:
1. EACMS; and
responsibilities, responders, or
2. PACS 3. Dated and revised recovery plan
technology that the Responsible
with changes to the roles or
Entity determines would impact the
Medium Impact BES Cyber Systems at responsibilities, responders, or
ability to execute the recovery plan:
Control Centers and their associated: technology; and
1. EACMS; and 3.2.1. Update the recovery plan;
4. Evidence of plan update
2. PACS and
distribution including, but not
3.2.2. Notify each person or limited to:
group with a defined role in
the recovery plan of the • Emails;
updates. • USPS or other mail service;
• Electronic distribution system;
or

• Training sign-in sheets.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for updating the recovery plan and communicating recovery plan updates to all relevant
stakeholders. Customers should review Azure documentation on availability and resiliency.

Cloud Provider Responsibility: Yes

NIST 800-53 CP-4 Contingency Plan Testing: As a result of the testing performed, the Business Continuity Plan (BCP) Team,
in conjunction with the service teams, reviews supporting evidence documented in Team Foundation Services (TFS) and
identifies improvement opportunities for short, medium, and long-term follow-up. If critical issues are identified during
an exercise, they are worked on until resolution, and contingency plans get updated accordingly as needed. The overall
readiness of the Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) includes the readiness to execute the
plan per the test results.

As stated in the Business Continuity and Disaster Recover SOP, the BCP and DRP documents are reviewed on annual basis
or when required to address changes to the organization, information system, or environment of operation and problems
encountered during plan implementation, execution, or testing. This review and revision ensure that the information
included in the documents is accurate and up-to-date. Evidence of review is captured in the version history section of the
documents. In addition, the BCP and DRP documents are updated after major releases or updates. Whenever there are
major changes to the BCP document, the BPD also communicates the updated document to the key personnel involved in
the BCP process. The BCP is distributed in hardcopy to the Microsoft Azure NOC and is available on the Microsoft Azure
Business Continuity SharePoint site. The Microsoft Azure Operations Managers alias is notified when changes are made.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 163
Cloud Implementation Guide for NERC Audits

This alias includes all core personnel responsible for leading the platform recovery.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 337 Covers NIST 800-53 CP-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Business Continuity Business Continuity 2018.02 11/5/2018 21 CIP-009-6 R3.1
and Disaster Recovery and Disaster Recover
(AZURE) 2018.02.docx SOP

MICROSOFT CONFIDENTIAL – NDA REQUIRED 164

Cloud Implementation Guide for NERC Audits

CIP-010-2 – Cyber Security – Configuration Change Management and

Vulnerability Assessments
R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-010-2 Table R1 – Configuration Change Management. [Violation Risk
Factor: Medium] [Time Horizon: Operations Planning].
M1. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-010-2 Table R1 – Configuration Change Management and additional
evidence to demonstrate implementation as described in the Measures column of the table.

R1 Part 1.1

CIP-010-2 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures

1.1 High Impact BES Cyber Systems and Develop a baseline configuration, Examples of evidence may include, but are
their associated: individually or by group, which shall not limited to:
1. EACMS; include the following items: • A spreadsheet identifying the
2. PACS; and 1.1.1 Operating system(s) required items of the baseline
3. PCA (including version) or configuration for each Cyber Asset,
firmware where no individually or by group; or
Medium Impact BES Cyber Systems independent operating • A record in an asset management
and their associated: system exists; system that identifies the required
1. EACMS; 1.1.2 Any commercially available items of the baseline configuration
or open-source application for each Cyber Asset, individually
2. PACS; and
software (including version) or by group.
3. PCA intentionally installed;
1.1.3 Any custom software
installed;
1.1.4 Any logical network
accessible ports; and
1.1.5 Any security patches
applied.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for managing and maintaining the Operating System (OS) baseline configuration for
Infrastructure as a Service (IaaS) guest Virtual Machines (VMs), e.g., a non-Microsoft provided OS. Moreover, Registered
Entity is responsible for maintaining any application baselines deployed to the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-2 Baseline Configuration: Microsoft Azure reviews and updates configuration settings and baseline
configurations of hardware, software and network devices annually. Changes are developed, tested, and approved prior
to entering the production environment from a development and/or test environment.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 165

Cloud Implementation Guide for NERC Audits

Microsoft Azure applies baseline configurations using the Microsoft Security Development Lifecycle (SDL) process for
Microsoft Azure software components and bootstrap configuration process for hardware and network device components
entering Microsoft Azure production environment.

Baseline configurations of Microsoft Azure components/roles are documented, managed and maintained along with the
source code in the Source Depot and Git version control repositories. Access to Source Depot and Git is restricted using
the RAMWeb tool.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 259-260 Covers NIST 800-53 CM-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.2

CIP-010-2 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures

1.2 High Impact BES Cyber Systems and Authorize and document changes Examples of evidence may include, but are
their associated: that deviate from the existing not limited to:
1. EACMS; baseline configuration. • A change request record and
2. PACS; and associated electronic authorization
3. PCA (performed by the individual or
group with the authority to
Medium Impact BES Cyber Systems authorize the change) in a change
and their associated: management system for each
4. EACMS; change; or
5. PACS; and • Documentation that the change
6. PCA was performed in accordance with
the requirement.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for authorizing and documenting changes that deviate from existing baseline
configurations applicable to assets deployed in the cloud.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-2 Baseline Configuration: Baseline configuration changes to software components are thoroughly
reviewed and tested in the development environment before entering the Microsoft Azure production environment as
part of the Security Development Lifecycle (SDL) and change and release management processes. Changes to baseline
configurations go through the Microsoft SDL process, which requires security sign-offs prior to production deployment.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 166
Cloud Implementation Guide for NERC Audits

Baseline configurations of Microsoft Azure components/roles are documented, managed and maintained along with the
source code in the Source Depot and Git version control repositories. Access to Source Depot and Git is restricted using
the RAMWeb tool.

Changes to the Microsoft Azure component/role baseline configurations are deployed to the production environment
using the change and release management process. The change and release management process validates that the build
moves from one environment to the other with designated sign-offs by appropriate Microsoft Azure component team
personnel. Access to migrate changes to production is restricted.

NIST 800-53 CM-3 Configuration Change Control: Changes to operational systems, other than security patches, can only
be made when there is a valid business reason (e.g. a planned upgrade to the system). Changes implemented within the
production environment are categorized into Request for Change (RFC) types to appropriately schedule, align resources,
and provide change metrics back into the change process for continuous improvement. In general, the Microsoft Azure
services teams use the following change types: Major Release, Minor Release, and Revision Release.

All changes to the system under configuration control are reviewed, and approved or disapproved with explicit
consideration for security impact analysis.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 260 Covers NIST 800-53 CM-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 272 Covers NIST 800-53 CM-3

R1 Part 1.3

CIP-010-2 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures

1.3 High Impact BES Cyber Systems and For a change that deviates from the An example of evidence may include, but is
their associated: existing baseline configuration, not limited to, updated baseline
1. EACMS; update the baseline configuration as documentation with a date that is within 30
2. PACS; and necessary within 30 calendar days of calendar days of the date of the completion
3. PCA completing the change. of the change.

Medium Impact BES Cyber Systems

and their associated:
1. EACMS;
2. PACS; and
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:

MICROSOFT CONFIDENTIAL – NDA REQUIRED 167

Cloud Implementation Guide for NERC Audits

Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for

Cloud Provider Responsibility: Yes

NIST 800-53 CM-2(1) Baseline Configuration | Reviews and Updates: Microsoft Azure reviews and updates the operating
system (OS) and component baseline configurations when required due to a significant change. Changes from the United
States Cyber Command (USCYBERCOM) tactical orders/directives can be accommodated. However, analysis is required to
determine if any particular directive is applicable to the Microsoft Azure services. There is a reasonable probability that
any particular directive will be not applicable. Microsoft internal components are specifically engineered for its operations
and do not rely on third-party applications. They are further isolated from direct external connections. They must be
further tested to ensure that there is no detrimental impact to the baseline configurations and that the associated
vulnerability is not already accommodated by compensating/mitigating controls.

Microsoft Azure reviews and updates the applicable baseline configurations as part of the new OS or component-specific
release and upgrades. Azure publishes new OS configuration baselines every 30 days, internally. The new baselines are
intended to be implemented across Azure in as near to real time as possible.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 266-267 Covers NIST 800-53 CM-2(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.4

CIP-010-2 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures

1.4 High Impact BES Cyber Systems and For a change that deviates from the An example of evidence may include, but is
their associated: existing baseline configuration: not limited to, a list of cyber security
1. EACMS; 1.4.1 Prior to the change, controls verified or tested along with the
2. PACS; and determine required cyber dated test results.
3. PCA security controls in CIP-005
and CIP-007 that could be
Medium Impact BES Cyber Systems impacted by the change;
and their associated: 1.4.2 Following the change, verify
1. EACMS; that required cyber security
2. PACS; and controls determined in 1.4.1
3. PCA are not adversely affected;
and
1.4.3 Document the results of the
verification.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 168

Cloud Implementation Guide for NERC Audits

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for determining the impact of baseline configuration changes on other controls and
verifying that these controls are not adversely affected.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-4 Security Impact Analysis: As part of the Security Development Lifecycle (SDL) process, Microsoft Azure
analyzes software and hardware changes to determine potential security impacts prior to change implementation.
Changes are required to be documented, tested, and approved by appropriate personnel.

Additionally, for all asset types, changes are analyzed as part of the standard change management process, both prior to
and after implementation, to verify that what was modified resulted in expected output. Prior to the change being
implemented, information security impact analysis is performed and reviewed by each service team using their individual
processes.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 277 Covers NIST 800-53 CM-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 169

Cloud Implementation Guide for NERC Audits

R1 Part 1.5

CIP-010-2 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures
High Impact BES Cyber Systems
1.5 Where technically feasible, for each An example of evidence may include, but is
change that deviates from the not limited to, a list of cyber security
existing baseline configuration: controls tested along with successful test
1.5.1 Prior to implementing any results and a list of differences between the
change in the production production and test environments with
environment, test the descriptions of how any differences were
changes in a test accounted for, including of the date of the
environment or test the test.
changes in a production
environment where the test
is performed in a manner
that minimizes adverse
effects, that models the
baseline configuration to
ensure that required cyber
security controls in CIP-005
and CIP-007 are not
adversely affected; and
1.5.2 Document the results of the
testing and, if a test
environment was used, the
differences between the test
environment and the
production environment,
including a description of the
measures used to account
for any differences in
operation between the test
and production
environments.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for validating changes to baseline configurations in a test environment. If testing is
conducted in a production environment, Registered Entity should take appropriate measures to minimize adverse effects
or impact on other relevant security controls.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-2 Baseline Configuration: Baseline configuration changes to software components are thoroughly
reviewed and tested in the development environment before entering the Microsoft Azure production environment as
part of the Security Development Lifecycle (SDL) and change and release management processes. Changes to baseline
configurations go through the Microsoft SDL process, which requires security sign-offs prior to production deployment.
Baseline configurations of Microsoft Azure components/roles are documented, managed and maintained along with the
source code in the Source Depot and Git version control repositories. Access to Source Depot and Git is restricted using

MICROSOFT CONFIDENTIAL – NDA REQUIRED 170

Cloud Implementation Guide for NERC Audits

the RAMWeb tool.

Changes to the Microsoft Azure component/role baseline configurations are deployed to the production environment
using the change and release management process. The change and release management process validates that the build
moves from one environment to the other with designated sign-offs by appropriate Microsoft Azure component team
personnel. Access to migrate changes to production is restricted.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 260 Covers NIST 800-53 CM-2
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-010-2 Table R2 – Configuration Monitoring. [Violation Risk Factor:
Medium] [Time Horizon: Operations Planning].
M2. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-010-2 Table R2 – Configuration Monitoring and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R2 Part 2.1

CIP-010-2 Table R2 – Configuration Monitoring

Part Applicable Systems Requirements Measures

2.1 High Impact BES Cyber Systems Monitor at least once every 35 An example of evidence may include, but is not
and their associated: calendar days for changes to the limited to, logs from a system that is
1. EACMS; and baseline configuration (as described monitoring the configuration along with
2. PCA in Requirement R1, Part 1.1). records of investigation for any unauthorized
Document and investigate detected changes that were detected.
unauthorized changes.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for monitoring changes to BES Cyber Systems baseline configurations and investigating
detected unauthorized changes. Customers can use Azure Security Center to monitor their Azure resources and leverage
extensive logging capability built into Azure.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 171

Cloud Implementation Guide for NERC Audits

Cloud Provider Responsibility: Yes

Microsoft does not inspect, approve, or monitor customer applications in Azure. Microsoft does not know how a BES
Cyber System is configured or what constitutes proper baseline configuration for a BES Cyber System. Consequently,
Microsoft cannot monitor processes that Registered Entity put in place to detect unauthorized modifications to BES Cyber
Systems. Registered Entity is wholly responsible for monitoring BES Cyber Systems and detecting any unauthorized
modifications.

NIST 800-53 CM-2(1) Baseline Configuration | Reviews and Updates: Microsoft Azure reviews and updates the applicable
baseline configurations as part of the new OS or component-specific release and upgrades. Azure publishes new OS
configuration baselines every 30 days, internally. The new baselines are intended to be implemented across Azure in as
near to real time as possible.

NIST 800-53 CM-3 Configuration Change Control: Microsoft Azure service teams use TFS, Source Depot and Git to
document evidence of approval and track all changes. These tools provide an auditing capability to any changes to the
baselines or configuration changes within the tools. Microsoft Azure uses Source Depot and Git as the versioning systems
for software code. Both of these tools track the identity of the person who checks code out, the time of the change, and
what changes are made to what files. Software and hardware changes are tracked through TFS. In addition, an annual
external audit is performed on the Microsoft Azure change management process as part of annual Microsoft Azure
security assessment. As part of the audit, a sample of changes are selected and reviewed to determine if the change
management process is consistently being followed.

NIST 800-53 CM-5 Access Restrictions for Change: Microsoft Azure service teams define, document, approve, and enforce
logical access restrictions associated with changes by using Role-Based Access Control (RBAC) enforced by Active Directory
(AD). All accounts created in support of Microsoft Azure are role-based. Service team personnel request access to, and if
approved, are placed in the appropriate security groups according to their roles for supporting the system and using the
principle of least privilege. Access to the production environment is only allowed to members of specific security groups
after approval. This process ensures that no unauthorized changes are made to baselines.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 267 Covers NIST 800-53 CM-2(1)
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 273-274 Covers NIST 800-53 CM-3
“ “ “ “ 278 Covers NIST 800-53 CM-5

MICROSOFT CONFIDENTIAL – NDA REQUIRED 172

Cloud Implementation Guide for NERC Audits

R3 Supporting Evidence and Documentation

R3. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of
the applicable requirement parts in CIP-010-2 Table R3– Vulnerability Assessments. [Violation Risk Factor:
Medium] [Time Horizon: Long-term Planning and Operations Planning]
M3. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-010-2 Table R3 – Vulnerability Assessments and additional evidence to
demonstrate implementation as described in the Measures column of the table.

R3 Part 3.1

CIP-010-2 Table R3 – Vulnerability Assessments

Part Applicable Systems Requirements Measures

3.1 High Impact BES Cyber Systems and At least once every 15 calendar Examples of evidence may include, but
their associated: months, conduct a paper or active are not limited to:
1. EACMS; vulnerability assessment. • A document listing the date of the
2. PACS; and assessment (performed at least once
3. PCA every 15 calendar months), the
Medium Impact BES Cyber Systems controls assessed for each BES Cyber
and their associated: System along with the method of
assessment; or
1. EACMS; • A document listing the date of the
2. PACS; and assessment and the output of any
3. PCA tools used to perform the
assessment.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for vulnerability assessment of their applications deployed in the cloud. Customers should
review documentation on vulnerability assessment in Azure Security Center and penetration testing.

Cloud Provider Responsibility: Yes

NIST 800-53 CA-7 Continuous Monitoring: The Microsoft Azure Continuous Monitoring team performs correlation and
analysis of security-related information generated by assessments and monitoring, including vulnerability scan results,
Plan of Action and Milestones (POA&M) updates, and recurring control testing.

Any new deficiencies that are identified from the security control assessments are documented in the POA&M. The
POA&M is continuously updated and used to report on the security state of the information system as part of monthly
reviews. POA&M updates are reviewed and validated by Microsoft Azure’s third-party assessor organization (3PAO), and
are provided to customers and the FedRAMP Joint Authorization Board (JAB) monthly, consistent with FedRAMP
requirements.

• Microsoft performs vulnerability scanning of operating systems within the Microsoft Azure environment monthly, as
discussed in RA-5.
• Microsoft performs vulnerability scanning of databases and web applications within the Microsoft Azure environment
monthly, as discussed in RA-5.
MICROSOFT CONFIDENTIAL – NDA REQUIRED 173
Cloud Implementation Guide for NERC Audits

• As part of the annual reassessment of the Microsoft Azure FedRAMP package, Microsoft Azure employs a Third-Party
Assessor Organization (3PAO) to perform scans of the environment on an annual basis.

NIST 800-53 CA-8 Penetration Testing: An independent penetration testing team within Microsoft’s security organization
conducts annual unannounced penetration testing. Tests may be coordinated with Microsoft Azure management
personnel in order to mitigate risk to the availability of Microsoft Azure; however, Microsoft Azure management personnel
do not notify operational/technical personnel in these cases.

NIST 800-53 RA-5 Vulnerability Scanning: Microsoft Azure implements vulnerability scanning by actively scanning server
operating systems, physical servers, network devices, web applications, and databases in the Azure inventory with
authenticated scans. All scans are performed on a monthly basis. The vulnerability scanning tools provide reporting data
based on a number of existing, well-used, open standards that itemize software flaws, security configurations, and various
product names, including the Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System
(CVSS).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 245-246 Covers NIST 800-53 CA-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 248 Covers NIST 800-53 CA-8
“ “ “ “ 556-557 Covers NIST 800-53 RA-5

MICROSOFT CONFIDENTIAL – NDA REQUIRED 174

Cloud Implementation Guide for NERC Audits

R3 Part 3.2

CIP-010-2 Table R3 – Vulnerability Assessments

Part Applicable Systems Requirements Measures

3.2 High Impact BES Cyber Systems Where technically feasible, at least An example of evidence may include, but
once every 36 calendar months: is not limited to, a document listing the
3.2.1 Perform an active vulnerability date of the assessment (performed at
assessment in a test least once every 36 calendar months),
environment, or perform an the output of the tools used to perform
active vulnerability assessment the assessment, and a list of differences
in a production environment between the production and test
where the test is performed in environments with descriptions of how
a manner that minimizes any differences were accounted for in
adverse effects, that models conducting the assessment.
the baseline configuration of
the BES Cyber System in a
production environment; and
3.2.2 Document the results of the
testing and, if a test
environment was used, the
differences between the test
environment and the
production environment,
including a description of the
measures used to account for
any differences in operation
between the test and
production environments.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for vulnerability assessment of their applications deployed in the cloud. Customers should
review documentation on vulnerability assessment in Azure Security Center and penetration testing.

Cloud Provider Responsibility: Yes

NIST 800-53 CA-7 Continuous Monitoring: The Microsoft Azure Continuous Monitoring team performs correlation and
analysis of security-related information generated by assessments and monitoring, including vulnerability scan results,
Plan of Action and Milestones (POA&M) updates, and recurring control testing.

Any new deficiencies that are identified from the security control assessments are documented in the POA&M. The
POA&M is continuously updated and used to report on the security state of the information system as part of monthly
reviews. POA&M updates are reviewed and validated by Microsoft Azure’s third-party assessor organization (3PAO), and
are provided to customers and the FedRAMP Joint Authorization Board (JAB) monthly, consistent with FedRAMP
requirements.

• Microsoft performs vulnerability scanning of operating systems within the Microsoft Azure environment monthly, as
discussed in RA-5.
• Microsoft performs vulnerability scanning of databases and web applications within the Microsoft Azure environment
MICROSOFT CONFIDENTIAL – NDA REQUIRED 175
Cloud Implementation Guide for NERC Audits

monthly, as discussed in RA-5.

• As part of the annual reassessment of the Microsoft Azure FedRAMP package, Microsoft Azure employs a Third-Party
Assessor Organization (3PAO) to perform scans of the environment on an annual basis.

NIST 800-53 CA-8 Penetration Testing: An independent penetration testing team within Microsoft’s security organization
conducts annual unannounced penetration testing. Tests may be coordinated with Microsoft Azure management
personnel in order to mitigate risk to the availability of Microsoft Azure; however, Microsoft Azure management personnel
do not notify operational/technical personnel in these cases.

NIST 800-53 RA-5 Vulnerability Scanning: Microsoft Azure implements vulnerability scanning by actively scanning server
operating systems, physical servers, network devices, web applications, and databases in the Azure inventory with
authenticated scans. All scans are performed on a monthly basis. The vulnerability scanning tools provide reporting data
based on a number of existing, well-used, open standards that itemize software flaws, security configurations, and various
product names, including the Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Scoring System
(CVSS).

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 245-246 Covers NIST 800-53 CA-7
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 248 Covers NIST 800-53 CA-8
“ “ “ “ 556-557 Covers NIST 800-53 RA-5

R3 Part 3.3

CIP-010-2 Table R3 – Vulnerability Assessments

Part Applicable Systems Requirements Measures

3.3 High Impact BES Cyber Systems and Prior to adding a new applicable An example of evidence may include, but
their associated: Cyber Asset to a production is not limited to, a document listing the
environment, perform an active date of the assessment (performed prior
1. EACMS;
vulnerability assessment of the new to the commissioning of the new Cyber
2. PCA Cyber Asset, except for CIP Asset) and the output of any tools used
Exceptional Circumstances and like to perform the assessment.
replacements of the same type of
Cyber Asset with a baseline
configuration that models an existing
baseline configuration of the
previous or other existing Cyber
Asset.

Cloud Provider Response (Required):

Compliance Narrative:

MICROSOFT CONFIDENTIAL – NDA REQUIRED 176

Cloud Implementation Guide for NERC Audits

Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for vulnerability assessment of their applications deployed in the cloud. Customers should
review documentation on vulnerability assessment in Azure Security Center and penetration testing.

Cloud Provider Responsibility: Yes

NIST 800-53 CM-4 Security Impact Analysis: As part of the SDL process, Microsoft Azure analyzes software and hardware
changes to determine potential security impacts prior to change implementation. Changes are required to be
documented, tested, and approved by appropriate personnel.

Additionally, for all asset types, changes are analyzed as part of the standard change management process, both prior to
and after implementation, to verify that what was modified resulted in expected output. Prior to the change being
implemented, information security impact analysis is performed and reviewed by each service team using their individual
processes.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 277 Covers NIST 800-53 CM-4
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R3 Part 3.4

CIP-010-2 Table R3 – Vulnerability Assessments

Part Applicable Systems Requirements Measures

3.4 High Impact BES Cyber Systems and Document the results of the An example of evidence may include, but
their associated: assessments conducted according to is not limited to, a document listing the
1. EACMS; Parts 3.1, 3.2, and 3.3 and the action results or the review or assessment, a list
2. PACS; and plan to remediate or mitigate of action items, documented proposed
3. PCA vulnerabilities identified in the dates of completion for the action plan,
assessments including the planned and records of the status of the action
Medium Impact BES Cyber Systems
date of completing the action plan and items (such as minutes of a status
and their associated:
the execution status of any meeting, updates in a work order system,
1. EACMS; remediation or mitigation action items. or a spreadsheet tracking the action
2. PACS; and items).
3. PCA

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes

MICROSOFT CONFIDENTIAL – NDA REQUIRED 177

Cloud Implementation Guide for NERC Audits

Registered Entity is responsible for vulnerability assessment of their applications deployed in the cloud. Customers should
review documentation on vulnerability assessment in Azure Security Center and penetration testing.

Cloud Provider Responsibility: Yes

NIST 800-53 CA-5 Plan of Action and Milestones: Microsoft Azure develops Plan of Action and Milestones (POA&M) in
accordance with the Office of Management and Budget (OMB) guidance and FedRAMP requirements. The POA&M is
submitted as part of the Microsoft Azure Security Authorization Package provided to FedRAMP.

Microsoft updates the POA&M on at least a monthly basis based on the findings of the security control assessments and
ongoing continuous monitoring activities, including vulnerability scanning. Microsoft includes an action step to remediate
any high and medium items from ongoing assessments and vulnerability scans (if any) in the monthly POA&M submission.
For any high and medium items noted, Microsoft provides a high-level description of the issue and the remediation plan.
The raw scan reports contain details on any issues noted and are made available to FedRAMP on a monthly basis.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 239 Covers NIST 800-53 CA-5
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R4 Supporting Evidence and Documentation

R4. Each Responsible Entity, for its high impact and medium impact BES Cyber Systems and associated Protected
Cyber Assets, shall implement, except under CIP Exceptional Circumstances, one or more documented plan(s)
for Transient Cyber Assets and Removable Media that include the sections in Attachment 1. [Violation Risk
Factor: Medium] [Time Horizon: Long-term Planning and Operations Planning]
M4. Evidence shall include each of the documented plan(s) for Transient Cyber Assets and Removable Media that
collectively include each of the applicable sections in Attachment 1 and additional evidence to demonstrate
implementation of plan(s) for Transient Cyber Assets and Removable Media. Additional examples of evidence
per section are located in Attachment 2. If a Responsible Entity does not use Transient Cyber Asset(s) or
Removable Media, examples of evidence include, but are not limited to, a statement, policy, or other document
that states the Responsible Entity does not use Transient Cyber Asset(s) or Removable Media.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for implementing a documented plan for transient cyber assets and removable media.

Cloud Provider Responsibility: No

NIST 800-53 AC-19 Access Control for Mobile Devices: Mobile computing and data recording devices are not to be used in
any of Microsoft’s online services production environments without prior approval by the Datacenter Management Team

MICROSOFT CONFIDENTIAL – NDA REQUIRED 178

Cloud Implementation Guide for NERC Audits

via an access request. Microsoft Azure monitors for all unauthorized use of mobile devices in the Microsoft Azure
environment and performs investigations accordingly. Mobile computing and data recording devices include PDAs,
portable hard drives, laptop computers, flash drives, other recordable media, etc. Monitoring of unauthorized connections
of mobile devices to servers is implemented by security officers that observe that all mobile devices used on servers must
have corresponding entries in the DCAT system. Additionally, a green/red sticker system is used to identify authorized
devices.

NIST 800-53 MP-4 Media Storage: Microsoft Azure digital media assets are physically and securely stored within Microsoft
Azure datacenter colocation rooms. Microsoft Azure datacenters have multiple layers of physical access controls (access
badge, biometrics – see PE-03 in CIP-006-6 for further details on physical access controls) and video surveillance in place
to provide secure storage. Digital media includes servers, network devices, and magnetic tapes used for backup. Non-
digital media is not used by Microsoft Azure in the datacenter environment. Facilities define controlled areas as
appropriate for their footprint and layout. Any areas containing digital media assets are considered controlled regardless
of facility layout and are protected by the physical and environmental controls implemented in the PE family.

NIST 800-53 MP-7 Media Use: Asset owners are required to assign their assets with an asset classification and no assets
are exempt from this requirement. In the Microsoft Azure datacenter environment, assets refer to servers, network
devices, and magnetic tapes. Other digital media like USB flash/thumb drives are managed by policies and procedures that
are specific to those devices. CD/DVDs are not used. Non-digital media is not used in the datacenter. The usage of digital
media in Microsoft Azure datacenter environments is monitored 24x7 via CCTV coverage. Please see PE-06 in CIP-006-6
for more details. Media that is personally owned or has no identifiable owner is prohibited in any production area as noted
in the Microsoft Datacenter Work Rules and Regulations document.

Microsoft Tools and Removable Media Security Procedure provides guidelines for securing high-value tools and
removable media to comply with audit requirements in Microsoft Security Program Policy 04-03 Asset Handling (internal
link). This document also discusses proper auditing for the tools and removable media, to ensure they are on-site and in
working condition. Microsoft-furnished USB drives should be strictly used for the listed purposes and only Microsoft-
owned USB drives are allowed in the production space. These guidelines and criteria apply to all personnel, including
Microsoft employees and vendors within all Microsoft datacenters.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 162 Covers NIST 800-53 AC-19
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 473 Covers NIST 800-53 MP-4
“ “ “ “ 478-479 Covers NIST 800-53 MP-7
Tools and Removable Tools and Removable 9.0 8/27/2018 1-11 CIP-010-2 R4
Media Security Media Security
Procedure.pdf Procedure

MICROSOFT CONFIDENTIAL – NDA REQUIRED 179

Cloud Implementation Guide for NERC Audits

CIP-011-2 – Cyber Security – Information Protection

R1 Supporting Evidence and Documentation
R1. Each Responsible Entity shall implement one or more documented information protection program(s) that
collectively includes each of the applicable requirement parts in CIP-011-2 Table R1 – Information Protection.
[Violation Risk Factor: Medium] [Time Horizon: Operations Planning].
M1. Evidence for the information protection program must include the applicable requirement parts in CIP-011-2
Table R1 – Information Protection and additional evidence to demonstrate implementation as described in the
Measures column of the table.

R1 Part 1.1

CIP-011-2 Table R1 – Information Protection

Part Applicable Systems Requirements Measures
Examples of acceptable evidence include,
1.1 High Impact BES Cyber Systems and Method(s) to identify information
their associated: that meets the definition of BES but are not limited to:
1. EACMS; and Cyber System Information. • Documented method to identify
2. PACS BES Cyber System Information
Medium Impact BES Cyber Systems from entity’s information
and their associated: protection program; or
1. EACMS; and • Indications on information (e.g.,
2. PACS labels or classification) that
identify BES Cyber System
Information as designated in the
entity’s information protection
program; or
• Training materials that provide
personnel with sufficient
knowledge to recognize BES Cyber
System Information; or
• Repository or electronic and
physical location designated for
housing BES Cyber System
Information in the entity’s
information protection program.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for identifying information that meets the definition of BES Cyber System Information
(BCSI).

Cloud Provider Responsibility: No

Microsoft Azure personnel do not have access to customer data and do not know what kind of data customers store in
MICROSOFT CONFIDENTIAL – NDA REQUIRED 180
Cloud Implementation Guide for NERC Audits

Azure. Consequently, Microsoft is not responsible for classifying BCSI.

NIST 800-53 MP-1 Media Protection Policy and Procedures: Microsoft Azure has implemented media protection policy
through the publication of Microsoft Security Program Policy (MSPP) maintained by C+AI Security which describes how
important organizational records relating to the organization’s Information Security Program, independent of media type,
must be retained, stored, protected, and, if appropriate, destroyed according to the established information handling
procedures for the records. The Microsoft's Asset Classification Standard and Asset Protection Standard define
appropriate handling and protection procedures of assets based on their classification.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 469 Covers NIST 800-53 MP-1
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R1 Part 1.2

CIP-011-2 Table R1 – Information Protection

Part Applicable Systems Requirements Measures
Examples of acceptable evidence include,
1.2 High Impact BES Cyber Systems and Procedure(s) for protecting and
their associated: securely handling BES Cyber System but are not limited to:
1. EACMS; and Information, including storage, • Procedures for protecting and
2. PACS transit, and use. securely handling, which include
Medium Impact BES Cyber Systems topics such as storage, security
and their associated: during transit, and use of BES
1. EACMS; and Cyber System Information; or
2. PACS • Records indicating that BES Cyber
System Information is handled in a
manner consistent with the
entity’s documented procedure(s).

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring that end users configure their Web browsers and mobile devices to enable
encrypted communication to Microsoft Azure. Azure has extensive support for data encryption. Azure uses the Transport
Layer Security (TLS) protocol to protect data when it is traveling between Registered Entity and Azure services. TLS
provides strong authentication, message privacy, and integrity. Perfect Forward Secrecy (PFS) protects connections
between Customer’s client systems and Microsoft cloud services by generating a unique session key for every session a
Customer initiates. PFS protects past sessions against potential future key compromises. Connections also use RSA-based
2,048-bit encryption key lengths. This combination makes it difficult for someone to intercept and access data that is in
MICROSOFT CONFIDENTIAL – NDA REQUIRED 181
Cloud Implementation Guide for NERC Audits

transit. Customers should review Azure best practices for the protection of data in transit and configure HTTPS endpoints
for their resources provisioned in Azure to ensure that all traffic going to and from their Virtual Machines is encrypted.

Customers should also use HTTPS to access their storage accounts. Storage Account Key (SAK) controls all access to a
storage account, and access to data in a specific account is granted only to entities having the secret key for that account.
Storage keys are 512-bit long, and they are generated randomly when the storage account is created (or later at the
request of the customer). Registered Entity is responsible for safeguarding the SAKs in order to protect access to Azure
Storage.

Azure provides extensive options for data encryption at rest to help customers safeguard their data and meet their
compliance needs using both Microsoft managed encryption keys, as well as customer managed encryption keys.
Encryption support is in place for customer IaaS Virtual Machines (both Windows and Linux) and for customer data storage
repositories.

Azure SQL Database provides Transparent Data Encryption (TDE) at rest by default. TDE performs real-time encryption
and decryption operations on the data and log files. Database Encryption Key (DEK) is a symmetric key stored in the
database boot record for availability during recovery. It is secured via a certificate stored in the master database of the
server or an asymmetric key called TDE Protector stored under customer control in Azure Key Vault, which is Azure’s cloud-
based external key management system. Azure Key Vault supports Bring Your Own Key (BYOK), which enables customers
to store TDE Protector in Key Vault and control key management tasks including key rotation, permissions, deleting keys,
enabling auditing/reporting on all TDE Protectors, etc. See Always Encrypted for more information. Note that Always
Encrypted is a feature of Azure SQL Database designed specifically to protect sensitive data by allowing clients to encrypt
data inside client applications and never reveal the encryption keys to the Database Engine. In this manner, Always
Encrypted provides separation between those who own the data (and can view it) and those who manage the data (but
should have no access).

Key Vault uses FIPS 140-2 Level 2 validated Hardware Security Modules. Key Vault is designed, deployed, and operated
such that Microsoft personnel are precluded from accessing, using, or extracting any data stored in the Key Vault
service, including customer’s cryptographic keys.

Similarly, Azure Storage Service Encryption for Data at Rest ensures that data is automatically encrypted before persisting
it to Azure Storage and decrypted before retrieval. All data written to Azure Storage is encrypted through 256-bit AES
encryption, and the handling of encryption, decryption, and key management in Storage Service Encryption is transparent
to customers. However, customers can also use their own encryption keys for Azure Storage encryption at rest and
manage their keys in Azure Key Vault. Storage Service Encryption is enabled for all new and existing storage accounts and
cannot be disabled. Customers should review the Azure Storage security guide.

Cloud Provider Responsibility: Yes

NIST 800-53 SC-28 Protection of Information at Rest: Microsoft Azure protects information at rest by applying information-
handling procedures. Protections for information at rest are outlined in, but not limited to, the categories below:
• Access Control – Logical access to protected data at rest is controlled at various levels through technical means. Access
to servers where information is stored is restricted through Active Directory security group membership in the domain
where the server resides. Security groups that restrict access to information at rest are configured to allow the least
privilege possible to complete tasks. Any Azure administrator needing access must follow account creation or modification
procedures as outlined in AC-2.
• Technical means also create logical access control at the network layer. Router and firewall Access Control Lists (ACLs)
prevent servers that store data at rest from being exposed outside of the environment.
• Physical Access Controls – The Azure datacenter team maintains controls over physical access to the datacenter. The
server room environments have multiple access levels regulated with least privilege.
• For each block written to Azure Storage accounts, a compressed and uncompressed Cyclic Redundancy Check (CRC) is
MICROSOFT CONFIDENTIAL – NDA REQUIRED 182
Cloud Implementation Guide for NERC Audits

used to identify corrupted data.

NIST 800-53 MP-4 Media Storage: Microsoft Azure digital media assets are physically and securely stored within Microsoft
Azure datacenter colocation rooms. Microsoft Azure datacenters have multiple layers of physical access controls (access
badge, biometrics – see PE-03 in CIP-006-6 for further details on physical access controls) and video surveillance in place
to provide secure storage. Digital media includes servers, network devices, and magnetic tapes used for backup. Non-
digital media is not used by Microsoft Azure in the datacenter environment. Facilities define controlled areas as
appropriate for their footprint and layout. Any areas containing digital media assets are considered controlled regardless
of facility layout and are protected by the physical and environmental controls implemented in the PE family.

NIST 800-53 MP-5 Media Transport: Digital media at Microsoft Azure datacenters consist of servers, network devices, and
magnetic backup tapes and discs, where appropriate. Microsoft Azure datacenters do not use non-digital media. Microsoft
Azure utilizes 3 methods to protect media that is being transported outside the datacenter: 1) Secure Transport, 2)
Encryption, and 3) Cleanse, Purge, or Destroy. Microsoft Azure restricts the activities of asset transport to authorized
personnel through the protection of the chain of custody. The use of locks, tamper proof seals, and requiring validation of
the asset inventories ensures that only authorized personnel are involved in the asset transport.

NIST 800-53 MP-7 Media Use: Asset owners are required to assign their assets with an asset classification and no assets
are exempt from this requirement. In the Microsoft Azure datacenter environment, assets refer to servers, network
devices, and magnetic tapes. Other digital media like USB flash/thumb drives are managed by policies and procedures that
are specific to those devices. CD/DVDs are not used. Non-digital media is not used in the datacenter. The usage of digital
media in Microsoft Azure datacenter environments is monitored 24x7 via CCTV coverage. Please see PE-06 in CIP-006-6
for more details. Media that is personally owned or has no identifiable owner is prohibited in any production area as noted
in the Microsoft Datacenter Work Rules and Regulations document.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 657 Covers NIST 800-53 SC-28
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
“ “ “ “ 473 Covers NIST 800-53 MP-4
“ “ “ “ 475 Covers NIST 800-53 MP-5
“ “ “ “ 478-479 Covers NIST 800-53 MP-7

MICROSOFT CONFIDENTIAL – NDA REQUIRED 183

Cloud Implementation Guide for NERC Audits

R2 Supporting Evidence and Documentation

R2. Each Responsible Entity shall implement one or more documented process(es) that collectively include the
applicable requirement parts in CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal. [Violation Risk Factor:
Lower] [Time Horizon: Operations Planning].
M2. Evidence must include each of the applicable documented processes that collectively include each of the
applicable requirement parts in CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal and additional
evidence to demonstrate implementation as described in the Measures column of the table.

R2 Part 2.1

CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal

Part Applicable Systems Requirements Measures
Examples of acceptable evidence include,
2.1 High Impact BES Cyber Systems and Prior to the release for reuse of
their associated: applicable Cyber Assets that contain but are not limited to:
1. EACMS; BES Cyber System Information • Records tracking sanitization
2. PACS; and (except for reuse within other actions taken to prevent
3. PCA systems identified in the “Applicable unauthorized retrieval of BES
Systems” column), the Responsible Cyber System Information such as
Medium Impact BES Cyber Systems
Entity shall take action to prevent
and their associated: clearing, purging, or destroying; or
the unauthorized retrieval of BES
1. EACMS;
Cyber System Information from the • Records tracking actions such as
2. PACS; and encrypting, retaining in the
Cyber Asset data storage media.
3. PCA
Physical Security Perimeter or
other methods used to prevent
unauthorized retrieval of BES
Cyber System Information.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for ensuring data at rest is encrypted or deleted when no longer needed. Customers should
review online documentation on Azure Storage Service Encryption for Data at Rest. More information about customer
data deletion is available from the companion white paper “NERC CIP standards and cloud computing”.

Cloud Provider Responsibility: Yes

NIST 800-53 MP-6 Media Sanitization: In the Microsoft Azure datacenter environment, digital media is required to be
cleansed/purged using Microsoft approved tools and in a manner consistent with NIST SP 800-88 R1, Guidelines for Media
Sanitization, prior to being reused or disposed of. Non-digital media is not used by Azure in the datacenter environment.

Azure datacenters use data erasure processes to cleanse/purge data in a manner consistent with NIST SP 800-88 R1. For
assets requiring destruction, Azure utilizes onsite asset destruction services.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 184

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 477 Covers NIST 800-53 MP-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

R2 Part 2.2

CIP-011-2 Table R2 – BES Cyber Asset Reuse and Disposal

Part Applicable Systems Requirements Measures
Examples of acceptable evidence include,
2.2 High Impact BES Cyber Systems and Prior to the disposal of applicable
their associated: Cyber Assets that contain BES Cyber but are not limited to:
1. EACMS; System Information, the Responsible • Records that indicate that data
2. PACS; and Entity shall take action to prevent storage media was destroyed prior
3. PCA the unauthorized retrieval of BES to the disposal of an applicable
Cyber System Information from the Cyber Asset; or
Medium Impact BES Cyber Systems
Cyber Asset or destroy the data
and their associated: • Records of actions taken to
storage media.
1. EACMS; prevent unauthorized retrieval of
2. PACS; and BES Cyber System Information
3. PCA
prior to the disposal of an
applicable Cyber Asset.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
Registered Entity is not responsible for the disposal of physical infrastructure assets in Azure datacenters.

Cloud Provider Responsibility: Yes

NIST 800-53 MP-6 Media Sanitization: In the Microsoft Azure datacenter environment, digital media is required to be
cleansed/purged using Microsoft approved tools and in a manner consistent with NIST SP 800-88 R1, Guidelines for Media
Sanitization, prior to being reused or disposed of. Non-digital media is not used by Azure in the datacenter environment.

Azure datacenters use data erasure processes to cleanse/purge data in a manner consistent with NIST SP 800-88 R1. For
assets requiring destruction, Azure utilizes onsite asset destruction services.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 185

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 477 Covers NIST 800-53 MP-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 186

Cloud Implementation Guide for NERC Audits

CIP-014-2 – Physical Security

R1 Supporting Evidence and Documentation
R1. Each Transmission Owner shall perform an initial risk assessment and subsequent risk assessments of its
Transmission stations and Transmission substations (existing and planned to be in service within 24 months)
that meet the criteria specified in Applicability Section 4.1.1. The initial and subsequent risk assessments shall
consist of a transmission analysis or transmission analyses designed to identify the Transmission station(s) and
Transmission substation(s) that if rendered inoperable or damaged could result in instability, uncontrolled
separation, or Cascading within an Interconnection.
1.1. Subsequent risk assessments shall be performed:

• At least once every 30 calendar months for a Transmission Owner that has identified in its
previous risk assessment (as verified according to Requirement R2) one or more Transmission
stations or Transmission substations that if rendered inoperable or damaged could result in
instability, uncontrolled separation, or Cascading within an Interconnection; or
• At least once every 60 calendar months for a Transmission Owner that has not identified in its
previous risk assessment (as verified according to Requirement R2) any Transmission stations or
Transmission substations that if rendered inoperable or damaged could result in instability,
uncontrolled separation, or Cascading within an Interconnection.
1.2. The Transmission Owner shall identify the primary control center that operationally controls each
Transmission station or Transmission substation identified in the Requirement R1 risk assessment.
M1. Examples of acceptable evidence may include, but are not limited to, dated written or electronic documentation
of the risk assessment of its Transmission stations and Transmission substations (existing and planned to be in
service within 24 months) that meet the criteria in Applicability Section 4.1.1 as specified in Requirement R1.
Additionally, examples of acceptable evidence may include, but are not limited to, dated written or electronic
documentation of the identification of the primary control center that operationally controls each Transmission
station or Transmission substation identified in the Requirement R1 risk assessment as specified in Requirement
R1, Part 1.2.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for performing a risk assessment of its Transmission stations and Transmission substations.

Cloud Provider Responsibility: No

Not applicable.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
N/A N/A N/A N/A N/A N/A

MICROSOFT CONFIDENTIAL – NDA REQUIRED 187

Cloud Implementation Guide for NERC Audits

R2 Supporting Evidence and Documentation

R2. Each Transmission Owner shall have an unaffiliated third party verify the risk assessment performed under
Requirement R1. The verification may occur concurrent with or after the risk assessment performed under
Requirement R1.
2.1. Each Transmission Owner shall select an unaffiliated verifying entity that is either:

• A registered Planning Coordinator, Transmission Planner, or Reliability Coordinator; or

• An entity that has transmission planning or analysis experience.
2.2. The unaffiliated third-party verification shall verify the Transmission Owner’s risk assessment performed
under Requirement R1, which may include recommendations for the addition or deletion of a
Transmission station(s) or Transmission substation(s). The Transmission Owner shall ensure the
verification is completed within 90 calendar days following the completion of the Requirement R1 risk
assessment.
2.3. If the unaffiliated verifying entity recommends that the Transmission Owner add a Transmission
station(s) or Transmission substation(s) to, or remove a Transmission station(s) or Transmission
substation(s) from, its identification under Requirement R1, the Transmission Owner shall either, within
60 calendar days of completion of the verification, for each recommended addition or removal of a
Transmission station or Transmission substation:

• Modify its identification under Requirement R1 consistent with the recommendation; or

• Document the technical basis for not modifying the identification in accordance with the
recommendation.
2.4. Each Transmission Owner shall implement procedures, such as the use of non-disclosure agreements,
for protecting sensitive or confidential information made available to the unaffiliated third-party verifier
and to protect or exempt sensitive or confidential information developed pursuant to this Reliability
Standard from public disclosure.
M2. Examples of acceptable evidence may include, but are not limited to, dated written or electronic documentation
that the Transmission Owner completed an unaffiliated third verification of the Requirement R1 risk assessment
and satisfied all of the applicable provisions of Requirement R2, including, if applicable, documenting the
technical basis for not modifying the Requirement R1 identification as specified under Part 2.3. Additionally,
examples of evidence may include, but are not limited to, written or electronic documentation of procedures to
protect information under Part 2.4.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for retaining an unaffiliated third-party to verify the risk assessment completed for
Transmission stations and Transmission substations.

Cloud Provider Responsibility: No

Not applicable.

MICROSOFT CONFIDENTIAL – NDA REQUIRED 188

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
N/A N/A N/A N/A N/A N/A

R3 Supporting Evidence and Documentation

R3. For a primary control center(s) identified by the Transmission Owner according to Requirement R1, Part 1.2 that
a) operationally controls an identified Transmission station or Transmission substation verified according to
Requirement R2, and b) is not under the operational control of the Transmission Owner: the Transmission
Owner shall, within seven calendar days following completion of Requirement R2, notify the Transmission
Operator that has operational control of the primary control center of such identification and the date of
completion of Requirement R2.
3.1. If a Transmission station or Transmission substation previously identified under Requirement R1 and
verified according to Requirement R2 is removed from the identification during a subsequent risk
assessment performed according to Requirement R1 or a verification according to Requirement R2, then
the Transmission Owner shall, within seven calendar days following the verification or the subsequent
risk assessment, notify the Transmission Operator that has operational control of the primary control
center of the removal.
M3. Examples of acceptable evidence may include, but are not limited to, dated written or electronic notifications or
communications that the Transmission Owner notified each Transmission Operator, as applicable, according to
Requirement R3.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for notifying the Transmission Operator.

Cloud Provider Responsibility: No

Not applicable.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
N/A N/A N/A N/A N/A N/A

MICROSOFT CONFIDENTIAL – NDA REQUIRED 189

Cloud Implementation Guide for NERC Audits

R4 Supporting Evidence and Documentation

R4. Each Transmission Owner that identified a Transmission station, Transmission substation, or a primary control
center in Requirement R1 and verified according to Requirement R2, and each Transmission Operator notified
by a Transmission Owner according to Requirement R3, shall conduct an evaluation of the potential threats and
vulnerabilities of a physical attack to each of their respective Transmission station(s), Transmission substation(s),
and primary control center(s) identified in Requirement R1 and verified according to Requirement R2. The
evaluation shall consider the following:
4.1. Unique characteristics of the identified and verified Transmission station(s), Transmission substation(s),
and primary control center(s);
4.2. Prior history of attack on similar facilities taking into account the frequency, geographic proximity, and
severity of past physical security related events; and
4.3. Intelligence or threat warnings received from sources such as law enforcement, the Electric Reliability
Organization (ERO), the Electricity Sector Information Sharing and Analysis Center (ES-ISAC), U.S. federal
and/or Canadian governmental agencies, or their successors.
M4. Examples of evidence may include, but are not limited to, dated written or electronic documentation that the
Transmission Owner or Transmission Operator conducted an evaluation of the potential threats and
vulnerabilities of a physical attack to their respective Transmission station(s), Transmission substation(s) and
primary control center(s) as specified in Requirement R4.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
To the extent that primary control center or components of it are hosted in the cloud, Registered Entity would not be
responsible for conducting the evaluation of potential threats and vulnerabilities related to a physical attack on the
primary control center.

Cloud Provider Responsibility: Yes

NIST 800-53 AU-6 Audit Review, Analysis, and Reporting: When circumstances dictate a review of the auditing procedures
(i.e. change in risk level based on law enforcement information, intelligence information, etc.); the decision to modify the
audit procedures will be made by C+AI Security, including stakeholders from Policy and Governance, Security Architecture,
and Security Operations. Microsoft Azure Infrastructure will also make updates whenever a change occurs in the threat
environment as defined by authoritative sources. This satisfies audit review, analysis, and reporting through the effective
monitoring of potential security violations.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 204 Covers NIST 800-53 AU-6
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan

MICROSOFT CONFIDENTIAL – NDA REQUIRED 190

Cloud Implementation Guide for NERC Audits

R5 Supporting Evidence and Documentation

R5. Each Transmission Owner that identified a Transmission station, Transmission substation, or primary control
center in Requirement R1 and verified according to Requirement R2, and each Transmission Operator notified
by a Transmission Owner according to Requirement R3, shall develop and implement a documented physical
security plan(s) that covers their respective Transmission station(s), Transmission substation(s), and primary
control center(s). The physical security plan(s) shall be developed within 120 calendar days following the
completion of Requirement R2 and executed according to the timeline specified in the physical security plan(s).
The physical security plan(s) shall include the following attributes:
5.1. Resiliency or security measures designed collectively to deter, detect, delay, assess, communicate, and
respond to potential physical threats and vulnerabilities identified during the evaluation conducted in
Requirement R4.
5.2. Law enforcement contact and coordination information.
5.3. A timeline for executing the physical security enhancements and modifications specified in the physical
security plan.
5.4. Provisions to evaluate evolving physical threats, and their corresponding security measures, to the
Transmission station(s), Transmission substation(s), or primary control center(s).
M5. Examples of evidence may include, but are not limited to, dated written or electronic documentation of its
physical security plan(s) that covers their respective identified and verified Transmission station(s), Transmission
substation(s), and primary control center(s) as specified in Requirement R5, and additional evidence
demonstrating execution of the physical security plan according to the timeline specified in the physical security
plan.

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: No
To the extent that primary control center or components of it are hosted in the cloud, Registered Entity would not be
responsible for developing and implementing a physical security plan that covers cloud assets.

Cloud Provider Responsibility: Yes

NIST 800-53 PE-1 Physical and Environmental Protection Policy and Procedures: Microsoft Azure has implemented a
physical and environmental policy and procedures to allow for the secure operation of Azure networks and data centers.
The Microsoft Cloud Security Program Policy (MSPP), Physical and Environmental Security Standard, Asset Classification
Standard, and Asset Protection Standard, are all maintained by Azure Infrastructure – C+AI Security State Engineering (SSE)
and reviewed and published annually. These documents address the purpose, scope, roles, responsibilities, compliance
requirements, and required coordination among the various Azure organizations that provide physical and environmental
support to Microsoft’s online services. The objective of the Physical and Environmental Security policy in the Microsoft
Security Program Policy (MSPP) is to prevent unauthorized access, damage, or interference to Azure data centers. Details
on the physical and environmental security controls policy can be found in Section 7 of the Microsoft Cloud Security Policy.
Customers can download the Microsoft Cloud Security Policy from the Service Trust Portal (see FAQ and White Papers
section).

MICROSOFT CONFIDENTIAL – NDA REQUIRED 191

Cloud Implementation Guide for NERC Audits

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
Azure – FedRAMP Microsoft Azure 3.05 7/31/2018 Covers NIST 800-53 PE-1
Moderate System Moderate System
Security Plan v3.05.pdf Security Plan
Microsoft Cloud Microsoft Security N/A 2/1/2018 6-7 Covers Physical and
Security Policy.pdf Policy Program Environmental Security
(External)

R6 Supporting Evidence and Documentation

R6. Each Transmission Owner that identified a Transmission station, Transmission substation, or primary control
center identified in Requirement R1 and verified according to Requirement R2, and each Transmission Operator
notified by a Transmission Owner according to Requirement R3, shall have an unaffiliated third party review the
evaluation performed under Requirement R4 and the security plan(s) developed under Requirement R5. The
review may occur concurrently with or after completion of the evaluation performed under Requirement R4 and
the security plan development under Requirement R5.
6.1. Each Transmission Owner and Transmission Operator shall select an unaffiliated third-party reviewer
from the following:

• An entity or organization with electric industry physical security experience and whose review
staff has at least one member who holds either a Certified Protection Professional (CPP) or
Physical Security Professional (PSP) certification.
• An entity or organization approved by the ERO.
• A governmental agency with physical security expertise.
• An entity or organization with demonstrated law enforcement, government, or military physical
security expertise.
6.2. The Transmission Owner or Transmission Operator, respectively, shall ensure that the unaffiliated third-
party review is completed within 90 calendar days of completing the security plan(s) developed in
Requirement R5. The unaffiliated third-party review may, but is not required to, include recommended
changes to the evaluation performed under Requirement R4 or the security plan(s) developed under
Requirement R5.
6.3. If the unaffiliated third-party reviewer recommends changes to the evaluation performed under
Requirement R4 or security plan(s) developed under Requirement R5, the Transmission Owner or
Transmission Operator shall, within 60 calendar days of the completion of the unaffiliated third-party
review, for each recommendation:

• Modify its evaluation or security plan(s) consistent with the recommendation; or

• Document the reason for not modifying the evaluation or security plan(s) consistent with the
recommendation.
6.4. Each Transmission Owner and Transmission Operator shall implement procedures, such as the use of
non-disclosure agreements, for protecting sensitive or confidential information made available to the

MICROSOFT CONFIDENTIAL – NDA REQUIRED 192

Cloud Implementation Guide for NERC Audits

unaffiliated third-party reviewer and to protect or exempt sensitive or confidential information

developed pursuant to this Reliability Standard from public disclosure.
M6. Examples of evidence may include, but are not limited to, written or electronic documentation that the
Transmission Owner or Transmission Operator had an unaffiliated third party review the evaluation performed
under Requirement R4 and the security plan(s) developed under Requirement R5 as specified in Requirement R6
including, if applicable, documenting the reasons for not modifying the evaluation or security plan(s) in
accordance with a recommendation under Part 6.3. Additionally, examples of evidence may include, but are not
limited to, written or electronic documentation of procedures to protect information under Part 6.4

Cloud Provider Response (Required):

Compliance Narrative:
Provide a brief explanation, in your own words, of how you comply with this Requirement. References to supplied
evidence, including links to the appropriate page, are recommended.
Registered Entity Responsibility: Yes
Registered Entity is responsible for retaining an unaffiliated third-party to review the evaluation performed under
Requirement R4 and the security plan developed under Requirement R5.

Cloud Provider Responsibility: No

Not applicable.

Cloud Provider Evidence (Required):

The following information is requested for each document submitted as evidence. Also, evidence submitted should
be highlighted and bookmarked, as appropriate, to identify the exact location where evidence of compliance may
be found.
Revision Relevant
or Document Page(s) or Description of Applicability
File Name Document Title Version Date Section(s) of Document
N/A N/A N/A N/A N/A N/A

MICROSOFT CONFIDENTIAL – NDA REQUIRED 193