# 5 – Understand security standards and how they apply to your SAP workload
**How do you define the security standards and controls to align with the criticality of your SAP workload?** Standards are published documents that define the policies and procedures required to secure your systems following best practices for a product, organization, industry, or jurisdiction. They provide a framework against which your SAP workload can be evaluated. Some standards are mandatory to ensure compliance with regulatory requirements, while others are optional but help with establishing roles and responsibilities.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-5.html)
# Best Practice 5.1 – Define security roles and responsibilities
By defining the requirements to secure your SAP workloads, you can identify risks that must be addressed and ensure that security-related roles and responsibilities are appropriately assigned. In the suggestions, we discuss standards for AWS, SAP, and any service providers to form a baseline on which you can build your security strategy.
**Suggestion 5.1.1 - Understand the AWS shared responsibility model**
AWS is responsible for security of the cloud and you, as the customer, are responsible for security in the cloud. Be aware of and understand the following resources:
+ AWS Documentation: [AWS Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ AWS Documentation:[AWS Response to Abuse and Compromise](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/abuse-and-compromise.html)
+ AWS Documentation: [AWS Acceptable Use Policy](https://aws.amazon.com/aup/)
Understand the division of responsibilities between you and your partners in the context of the AWS shared responsibility model
**Suggestion 5.1.2 - Understand the security foundations across SAP and AWS including compliance certificates, reports, and attestations**
Understand the security standards and compliance certifications that SAP and AWS support. Determine which are relevant to your industry and country (for example, PCI-DSS, GDPR, HIPAA). These controls can help strengthen your own compliance and certification programs, and reduce the effort required to meet your security standards.
Refer to the SAP and AWS documentation for more details:
+ AWS Documentation: [AWS Compliance](https://aws.amazon.com/compliance)
+ AWS Documentation: [AWS Compliance Center](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ AWS Documentation: [Compliance Programs](https://aws.amazon.com/compliance/programs/)
+ AWS Documentation: [Compliance Services in Scope](https://aws.amazon.com/compliance/services-in-scope/)
+ SAP Documentation: [Trust Center](https://www.sap.com/about/trust-center.html)
**Suggestion 5.1.3 - Assess the security foundation of the service providers that support your SAP workload**
If you are dependent on third-party organizations to manage all or part of your SAP workload, assess the ability of the third party to meet the required security controls. This includes the legal and regulatory requirements mandated by your enterprise.
# Best Practice 5.2 – Classify the data within your SAP workloads
Data sensitivity can impact the controls required to mitigate risk. AWS suggests referring to standard frameworks within your industry or organization and adopting these to classify your SAP workloads and the data contained within them.
**Suggestion 5.2.1 - Determine data classification and handling requirements**
Identify any data classification frameworks already in place in your organization. These frameworks can help you to categorize data based on the sensitivity of information, such as data that must be safeguarded for confidentiality, integrity, and availability. [Standard classification models](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-models-and-schemes.html) exist, for example, the US Information Categorization Scheme, that may be customizable based on your industry, business, or IT requirements.
Understand how data should be handled according to the guidelines appropriate for the classification. This includes specific security controls related to standards or regulatory requirements, such as PCI-DSS or GDPR, and common privacy considerations, such as handling personal identifiable information (PII). The following documents provide additional information:
+ AWS Documentation: [Data Classification: Secure Cloud Adoption Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/data-classification/data-classification-overview.html)
+ AWS Documentation: [General Data Protection Regulation (GDPR) Center](https://aws.amazon.com/compliance/gdpr-center/)
+ [NIST Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
+ [ISO/IEC 27001:2013 FAQs](https://aws.amazon.com/compliance/iso-27001-faqs/)
+ Well-Architected Framework [Security]: [Data Protection](https://docs.aws.amazon.com/wellarchitected/latest/framework/a-data-protection.html)
**Suggestion 5.2.2 - Identify SAP data types with specific handling rules**
Based on the business processes supported by your SAP system, there may be requirements for the handling and storage of data. Familiarize yourself with the guidance for your location and industry. SAP examples may include:
+ Assess whether a digital payments add-on is necessary to protect stored cardholder data and ensure PCI compliance.
+ Assess HR data for data residency requirements, for example, some countries and jurisdictions might require data to be stored within a specific geographical location.
+ Consider which data may need to be scrambled in non-production systems to obscure sensitive data but maintain data integrity.
**Suggestion 5.2.3 - Classify all your workloads according to the defined framework**
Classify your SAP systems according to their business usage and the existence of critical data types. Transactional systems such as SAP ERP are more likely to contain sensitive data than analytical systems such as SAP BW or management systems such as Solution Manager, although this should be validated by functional and security experts.
Additionally, assess whether the same controls apply to non-production workloads. For example, do non-production workloads include production data and therefore must they adhere to the same security controls?
# Best Practice 5.3 – Assess the need for specific security controls for your SAP workloads
Based on the data classification, evaluate any controls that can help you to meet the standards and requirements established in the previous best practices. These include location, AWS account strategy and scrambling requirements for non-production SAP workloads.
**Suggestion 5.3.1 - Assess any geographical location requirements**
Your SAP workloads might be deployed in one or many AWS Regions and Availability Zones (AZs). Each AWS Region consists of multiple, isolated, and physically separate AZs within a geographic area. In addition to evaluating the Region for latency, resilience, and sustainability specifications, you should consider whether security and compliance requirements can be met. Examples of isolated Regions with specific operating jurisdictions include:
+ AWS GovCloud (US) - designed to host sensitive data, regulated workloads, and address the most stringent US government security and compliance requirements
+ Amazon Web Services in China - AWS has collaborated with local partners to ensure China’s legal and regulatory requirements are met
Some industries and countries will have data residency requirements that all customer content processed and stored in an IT system must remain within a specific country’s borders.
+ AWS Documentation: [AWS Security blogs for data residency](https://aws.amazon.com/blogs/security/tag/data-residency/)
Before deciding on a location, review the availability of services for that AWS Region to ensure that the services that you require are available.
+ AWS Documentation: [AWS Regional Services](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/)
**Suggestion 5.3.2 - Determine how your SAP workloads align with your AWS account strategy and landing zone**
An important consideration when running SAP workloads in AWS is the AWS account strategy and landing zone approach that you adopt to meet your organization’s security controls. You should consider separating SAP from non-SAP workloads and having production workloads in a separate account from non-production workloads.
Understand your organization’s existing AWS account management strategy, including the use of the AWS Organizations and AWS Control Tower. Consider isolating security and log capabilities into an isolated account. Refer to the following for additional details:
+ Well-Architected Framework [Security]: [AWS Account Management and Separation](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/aws-account-management-and-separation.html)
+ AWS Documentation: [Establishing your best practice AWS environment](https://aws.amazon.com/organizations/getting-started/best-practices/)
+ AWS Documentation: [Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ AWS Documentation:[AWS multi-account strategy for your AWS Control Tower landing zone](https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html)
The account strategy you adopt will also affect the network configuration within AWS. As part of determining the appropriate AWS account strategy for your SAP workloads you should consider the following:
+ Requirements for cross-account access, such as the need for setting up [VPC Peering](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) or [Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html) to allow communication between non-production and production systems. For example, the movement of SAP transports through your landscape.
+ Dependencies on shared services (such as directory management resources) and network management components that are deployed in different AWS accounts from your SAP workloads.
+ In addition to the core security services, such as IAM and network controls, consider how AWS managed security services can help achieve security goals or uplift your security posture. AWS provides security services to assist with web application firewalls, traffic auditing, DDOS protection, CVE management, configuration auditing, and virus and threat detection.
+ AWS Documentation: [AWS Foundational Security Best Practices Controls](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html)
**Suggestion 5.3.3 - Review the controls for data scrambling (if applicable)**
Many SAP customers rely on copies of production data for testing purposes, including regression and performance testing. If creating a copy of production data, decide which controls you must add to ensure that your production data is protected from unintended access and modifications.
Consider the following options:
+ Traditional data scrambling mechanisms provided by SAP or third-party providers
+ The use of additional accounts or network controls to limit access during a copy of production data
+ Use of a non-production account with the same controls as production
# Best Practice 5.4 – Create a strategy for managing security controls
Having evaluated business requirements based on data classification, create a strategy that balances the security controls of your broader organization with the application guides and open standards available. Take into consideration the implementation effort and acknowledge risk.
**Suggestion 5.4.1 - Identify a matrix to assess risk**
A range of risk management frameworks are available for specific industries and geographies. Understand the risk framework adopted by your organization and how this applies to managing risks related to your SAP workloads.
+ AWS Documentation: [Example Risk Matrix](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/governance.html)
+ AWS Blog: [Scaling a governance, risk, and compliance program for the cloud](https://aws.amazon.com/blogs/security/scaling-a-governance-risk-and-compliance-program-for-the-cloud/)
+ [NIST Risk Management Framework](https://www.nist.gov/cyberframework/risk-management-framework)
**Suggestion 5.4.2 - Evaluate security and compliance requirements mandated by your organization**
Consult with your cloud center of excellence, legal team, compliance teams, and managed service provider to understand their security baseline and how controls are enforced. Evaluate whether all of these controls can easily be applied to your SAP workload and identify areas that might require an exception, for example allow and deny lists for AWS services, inbound and outbound traffic flow and access restrictions.
**Suggestion 5.4.3 - Identify and agree on a process for exceptions**
In some situations, software, business, or support requirements for SAP might require you to deviate from the standard security patterns. Identify a process to agree and document any exceptions with a change advisory board or security design authority and reassess the process on a regular basis.
AWS Documentation: [Change Management in the Cloud](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)