Quality at SAP

SAP corporation is an international software company that have developed its own requirements regarding the quality of products it develop, maintain and support. Some of them comes from the ISO or other quality organisation around the world but SAP as a world leading company in software development have developed its owns over time.

The SAP Quality Goal for product development at SAP is based on the following quality topics:

• Customer View: Quality from a customer perspective (quality in use) based on customer feedback
• Service Quality: Compliance to service standards
• Process Quality: Compliance to process standards and corporate requirements
• Product Quality: Compliance to SAP Product Standards and architecture guidelines

From now on, we will focus on Product Quality and more specifically on Product Standards that is part of a more global SAP quality policy that cover a lot more than software product development.

Product Quality at SAP is named Product Standards, aka PS, and define software product qualities which need to be fulfilled by all SAP products to enable SAP‘s business model. To do so, product standards define requirements to enable selling SAP products worldwide, efficient support, reaching all kinds of users, mitigating risk of lawsuits, up- and cross-selling into existing customer landscapes, and so on.

SAP has integrated Product Standards into the development process to achieve transparency about SAP products' qualities.

PS Accessibility defines rules for incorporating accessibility into the software development lifecycle to ensure that the resulting products can be used by people with disabilities.

PS Business Configuration (BC) supports the delivery of pre-configured content. The standard ensures high-quality best practices process and configuration content delivery as part of the product.

PS Functional Correctness concerns the completeness and correctness of SAP software products for new and existing functionality.

PS Globalization aims to align SAP’s sales and country strategy with its development efforts. The standard contains technical facets related to internationalization that ensure that SAP creates products that are flexible to meet the needs of our users around the world. It also contains nontechnical facets related to localization and translation, which help plan the product’s release strategy.

PS Licensing manages the approval process for all use and distribution of commercial, open source and other third party software and services in SAP products.

PS Operations & Support defines the criteria needed to provide customers with a standardized management concept to operate the business processes and the underlying system landscape with optimal availability, optimal performance and lowest cost of ownership. In addition it provides the criteria needed for software components to be supportable in a most efficient way via SAP standardized support processes.

PS Performance defines criteria that guarantee good performance and scalability of components, scenarios, and processes for new developments and upgrades of SAP applications.

PS Security defines a state-of-the-art security concept for all SAP software. It addresses security vulnerabilities, security legal requirements, and SAP strategy topics related to security.

PS Software Lifecycle ensures and improves the technical product qualities that make SAP software available for use within enterprise system landscapes. This includes a secure and reliable software development, an efficient shipment, a straightforward installation and easy technical configuration as well as a smooth upgrade/update, and a flawless un-installation of SAP software.

The PS Documentation is no longer in place. However, SAP absolutely needs to provide product documentation with the software to customers. This is now ensured by the corporate task User Assistance (Product Documentation) in All Relevant Languages.

Product Standard Usability have also been phased out from the PS. For guidance on usability and user experience, Product Owner must now refer to the SAP’s Ux Design Community.

The Product Standards (PS) Compliance process is a process in where every SAP product needs to plan, implement, test, and report its fulfillment of the product standard requirements. This process is a lean type governance one.

The Product Owner is responsible for the requirements of the products, which includes the level of compliance with Product Standard Requirements. The deviations and non-applicability in Product Standard compliance are approved by the Product Owner with the exception of Corporate Product Standard requirements and the Product Standard Security, where separate or additional rules apply.

• Product Standard Assessments.
• Product Standard Licensing ensures compliance via approval process for the usage of commercial third party and open source software and services and a mandatory validation.
• Product Standard Security ensures compliance via the mandatory security validation. Due to security requirements, findings are reported via security messages.
• Information Lifecycle Management Check included into the Advanced Test Cockpit (ATC).

The PS Owners are no longer approving PS compliance deviations and non-applicability. They will focus on continuous improvement of Product Standards, PS education, PS consulting, and PS assessments. The Product Standard Owners will conduct PS assessments for products on an ongoing basis. PS assessments are applicable only to selected programs. The selection criteria are based on multiple product factors such as: strategic importance, risk level, planned or reported PS compliance etc.

The status of the Product Standards contribute to product readiness.

In order to obtain the required quality in the PS compliance process SAP require to follow some guidelines:

• Start the PS requirements compliance planning only after the PS requirements are fully understood.
• Discuss your planning and reporting with the local PS experts, in case that some additional clarifications are required.
• Request consulting from Product Standard Owner teams for additional support in the PS compliance planning and reporting process.

Product Standard Owners no longer approve deviations and non-applicability of requirements, but provide a risk statement instead. Approvals to Product Standard deviations and non-applicability is provided by the responsible Qualification Program Director (QPD) from the Premium Qualification Team after consultation with the Qualification Project Manager and the Product Owner / Technical Owner (“Product Owner” stands for SAP Development Partner Contact). The approval process for Corporate Product Standard deviations remains unchanged, i.e. approval by L1 Management.

• The Product Owner approves Product Standard compliance deviations and non-applicability with the exception of Corporate Requirements, that must be approved according to the respective approval process. Corporate PS requirements cannot be planned as not-compliant (“No”) or not-applicable (“N/A”).
• A mitigation plan is recommended for the PS compliance deviations.
• PSC tool based PS compliance planning and reporting is mandatory.
• Product Standards Owners focus on PS education, PS consulting, further development of the Product Standards, and PS assessments.
• PS assessments are applicable to selected programs.

Product Standards Assessment is a structured analysis, conducted by one or more PS Owners, to verify planned, developed, and reported PS compliance of the product. Not all products are subject to the PS assessment. The program selection is based on multiple influencing factors such as strategic importance, risk level, planned or reported PS compliance etc. Furthermore, not all product standards will be in the scope of each PS assessment. The product standards included in an assessment will also be determined based on the influencing factors mentioned above. PS Owners are making the final decision on which program will be assessed, and what is the scope of the corresponding assessment. If you want to improve and increase compliance for your delivery, you could request an assessment via email to SAP_Product_Standards.

The Assessment Lead, in alignment with the Program Lead (PL), evaluates the product components belonging to the corresponding programs in more detail. Dates, the detailed scope, and points of contact are determined as preparation for the next phase.

For the product standards that are in scope of the assessment, the corresponding PS Owners assess the product. The methods used are determined by the PS Owners, and consist of activities such as planning inspections, code inspections, interviews etc. At the end of this phase, the PS Owners summarizes the findings of the complete PS assessment.

The draft version of the findings is presented to the program. Action items with owners and dates are agreed upon. Follow-up activities are identified, and if agreement is reached, action items in Sirius will be created and a final summary email will be send by the assessment lead. If agreement on mandatory actions cannot be reached, the issue shall be decided by product standard sponsor together with senior management (L1 or L2) of the potential owner of the action.

If there are mandatory action items, the product is marked for a follow-up assessment. The follow-up assessment is planned and conducted in the same way as a product standard assessment. In this case, the mandatory action items from the assessment are the primary influencing factors when determining the scope of the follow-up assessment.

• Provide transparency about Product Standard compliance for the defined scope.
• Verify and ensure that products are delivered with the expected quality using a scalable approach.
• Enable qualified decisions regarding Product Standard compliance in the development units.

A Product Standard consists of a set of well-defined requirements. Product Standard requirements are defined to cover various needs and expectations:

• Generic to be applicable for all SAP products
• relevant for all kinds of SAP’s delivery modes such as “Cloud”, “On-Premise” and “On Mobile Device”
• cover legal requirements
• follow SAP internal rules and
• reflect cost aspects.

Each product standard requirement is assigned to one of the following categories:

• Corporate requirements, requirements in which non-compliance leads to high financial risk for SAP. Compliance is mandatory.
• Quality requirements, which standardize the quality of SAP products by enforcing a common set of characteristics expected by customers buying the SAP brand (what). Product Owner is responsible for planning.
• Architecture and technology requirements, which standardize the architecture and technology of SAP products by enforcing a common infrastructure to reduce total cost of ownership, total cost of development, and support costs (how). Development is responsible for planning.

The requirements are applicable as follows:

• Corporate requirements: to be fulfilled by each SAP product
• Quality-Always / Architecture & Technology Always requirements: valid for each SAP product
• Quality-Specific / Architecture & Technology Specific requirements: applicability to be evaluated per product

The product standards requirements are available internally at SAP as a Microsoft Excel sheet that contain a very comprehensive checklist that cover all the themes listed in the overview. Each item in the checklist can have a Yes/No/N.A. answer type.

Here is an example for performance :

The acquired-to-ship and vendor-branded reseller programs use the ‘Product Standard Compliance Checklist for Vendor Branded Reseller Partner’.

Requirements can be defined as corporate or non-corporate Requirement.

A corporate requirement is a rule to protect SAP as a company from material damage by taking into account legal implications, significant business risks and international standards.

Each topics covered by the PS have a huge documentation that details them.

In order to detail a bit at least one of them, I have chosen the security topic since I am currently working at the SAP Security Research.

SAP software runs critical business processes and manages most valuable assets and sensitive data of their customers and consumers. Providing secure access to and preserving integrity, confidentiality and availability, data protection and privacy of these processes and data is key to our success and must be enforced by all SAP products and services. To achieve these qualities, to prevent software security vulnerabilities, and to allow for regulatory compliant system and service operations, SAP software needs to follow a secure software development lifecycle which includes planning and design, architecture, implementation, test, release preparation, shipment, maintenance and support.

The following artefacts shall be produced as outcome of the secure SDL:

1. Security risk documentation: The results of security risk assessment workshops, conducted in order to identify and assess security risks of the product or service under development, shall be documented. Recommended methodologies for security risk assessments are product-level and scenario-level threat modellings. The documentation shall describe the identified risks, their assessment, risk responses, i.e. measures for managing the risks, as well as responsibilities (risk owner, risk responsible).
2. Data Protection Compliance Evaluation (DCPE): The DPCE has been implemented as part of the Security Hub in Sirius, where all SAP people can check the compliance to the fundamental privacy requirements and document the status accordingly. During the validation step for the product, Data Protection & Privacy will be evaluated, and the rating of privacy compliance for the product will influence the overall rating of the security validation of the product.
3. Security Plan: The Security plan contains the decided measures (see picture above) and documents per each measure which test method is chosen to verify that the measure is mitigating the risk and is implemented correctly.
4. Product Standard Security Declaration: For transparency and comparability, declare whether and how far the requirements of the product standard security for your product or service have been met. The statement about the product standard security shall be based on and be consistent with the security risk assessment and the security plan.
5. Security Validation Report: All SAP software shall pass security validation as performed by the SAP Security Validation service before release. A security validation report is created by the validation team documenting the results.
6. Security Response Plan: All SAP software made available to customers and users has to support the SAP Security Response process. The product or service accountables shall ensure the required knowledge about this process and plan capacity in their teams.

For documentation of security risks, plans and reports, Products Owner shall use the respective functionality in SIRIUS (“Security Hub”). During execution of the security plan, the documents shall be kept updated for reporting.

Sufficient Security Awareness, Training and Education of all development and development-related roles in the product or service team are considered a prerequisite to comply with this requirement. Beyond that, there are further optional measures and artefacts that can help to achieve the desired security level of SAP software, such as code reviews or external security assessments.

By introducing the risk-based secure Software Development Lifecycle the product standard security acts as product security knowledge base containing best practices of secure software development and as a threat-library for the program specific risk assessment. The question whether a program needs to comply with a product standard requirement or not depends on the underlying risk that was identified and rated during the risk assessment. According to the lean governance concept the Product Owner is responsible to ensure an adequate security level in the product by managing risks and mitigations diligently. As a consequence a program can decide which risks can be accepted and which risks need to be partly or full mitigated, as long corporate requirements are not violated.

In case of corporate violations in addition an exceptional approval needs to be requested.

List of the requirements is provided in the table below ordered by relevant security topics. In addition, further columns of the table indicate if a requirement belongs to (A) Regulatory Compliance (B) Vulnerability Prevention (C) Strategy and Reduction of Attack Surface.

There's a wiki page per requirements so Product Owner at SAP can have all the technical details easily.

Corporate Requirements and Corporate Product Standard Requirements explained in context of product security and data protection & privacy:

SAP has defined a Corporate Requirement Framework as part of the Global Development Policy.

A corporate requirement in this framework is defined as a rule to protect SAP as a company from material damage by taking into account legal implications, significant business risks and international standards. The SAP Quality Management (QM) Board approves and enacts the Corporate Requirements. All SAP units including affiliates and acquired companies have to comply with each corporate requirement.

For Security and Data Protection & Privacy two corporate requirements are relevant:

• Develop and Operate Secure Software Products. The requirement describes verbally all the tasks of the Secure Software Development Lifecycle and the responsibilities of everyone involved in secure product development and also defines when and by whom exceptions need to be requested.
• Data Protection & Privacy Compliance. The requirement describes all mandatory tasks and refers to corporate product standard requirements to be fulfilled in order to get compliant.
  In particular it mandates:
  • Perform a Data Protection Compliance Evaluation
  • Plan and ensure compliance with the corporate product standard requirements (see below).

A Corporate Requirement can also define certain product standard requirements as corporate. That means non-compliance of a corporate product standard requirement leads automatically to non-compliance to the referring Corporate Requirement of the Corporate Requirement Framework.

For Data Protection & Privacy currently five corporate requirements are defined as part of the Product Standard Security:

• SEC-254 - Log read access to sensitive personal data
• SEC-255 - Provide a retrieval function which can be used to inform the data subjects about the personal data stored about them.
• SEC-256 - Erase personal data when all applicable retention periods have expired
• SEC-265 - Log changes to personal data
• SEC-224 - Capture explicit user consent before collecting any personal data.

In case of deviations of one or more of these corporate product standard requirements an exceptional approval needs to be requested.

The Global Security Policy is a criticality driven approach. The Corporate requirement Develop and Operate Secure Software Products defines the following non-compliance:

• Known open vulnerabilities with CVSS (Common Vulnerability Scoring System) base score >=7.0 are going to be delivered or re-delivered to customers in a new release or support package

Besides of corporate product standard requirement deviations a corporate requirement non-compliance can also happen in case of a process violation.

For Security and DPP (Data Protection & Privacy) this means:

• A Security Validation Report is rated by two stars or less can be considered as a process violation and exceptional approval needs to requested