Auditing SAP's Cloud Practices
a weblog, by Mark S. Ciminello, MBA, PMP, CISSP, CCSP
updated March 5, 2020
Mark Ciminello is SAP’s Principal Engineer for Cloud Security in the domains of Cloud (hosting), InfoSec, Data Privacy, Legal and Regulatory Compliance within the SAP Global Security organization. He lives in the Phoenix area and has been with SAP since 2010, bringing well over 35+ years of experience in Project Management, Information Security and Cloud.
I must get this one request from nearly every customer I talk to: "We want to be able to audit SAP as needed and want SAP's cooperation and support."
As a Certified Cloud Security Professional (CCSP), I understand the ask. I get that customers need to keep an eye on the ball and I see that as a good thing, one that is a smart ask from the customer. If I were in their shoes I would want the same thing. In fact, I would require it. I would require my cloud provider to support my diligence and would likely not enter into any contractual obligation or certainly not a business partnership with the provider unless they agreed to promote transparency and provide assurances of reasonable and appropriate security controls. To me, this is paramount to the relationship; I would expect nothing less of my provider.
The CCSP credential recommends the practice of transparency through audits.
Further, within the Data Privacy industry, the Industry Association of Privacy Professionals (IAPP) also recommends the same.
But SAP is a very large Cloud Service Provider (CSP) and there are certain challenges and problematic logistical issues for us, as SAP customers increasingly move to the cloud. Further, as SAP now partners with the hyperscalers such as Microsoft (Azure), Amazon (AWS) and Google (Cloud Platform), this promotes an exponential factor in cloud-based revenue for SAP.
As such, I wanted to share some of my thoughts on the logistics of the issue, and provide some practical insights as to how SAP customers can keep an eye on the ball while not falling asleep at the wheel, then offer some guidance as to how they can get the information they need to do their diligence - from someone within the SAP organization.
Auditing the SAP Cloud (including hyperscalers)
For customers, security audits are the expected method of managing and monitoring the CSP/customer relationship. For small cloud companies that only have a few customers, a few hundred or even a few thousand, this is quite manageable. They have the resources and the wherewithal to support limited scope audits, the volume of requests is easily scalable and if the cloud supplier is exceptionally hungry to acquire new business (typically ignoring cost and feasibility), they agree to support them. But note that it may have long term consequences for execution as a cloud provider grows.
As I write, SAP has grown to more than 450,000 customers. This presents a logistical challenge to SAP to accommodate the audit needs of that many customers. What would happen if all of them needed to audit SAP?
Not surprisingly, this position and the recognition of scalability for CSP's is supported by both the AICPA (American Institute of Certified Public Accountants) and the AIA (Association of International Accountants). Both professional organizations recognize the unique aspects of cloud computing and cloud service providers, and understand the problems of scalability of CSP audits. The recommendation of both organizations is that Service Organization Controls reports (SOC) be leveraged instead - more on that below.
So now you ask, what about transparency? Accountability? Assurances? We need the ability to audit SAP when it makes sense to do so.
SAP agrees.
SAP does support direct audits, and agrees to cooperate with our customers.
SAP Supports Direct Audits
SAP supports direct audits when they are warranted and justified. SAP has constrained the use of direct audits however, to justifiable validity, as audits - involving SAP, customers, auditors or other interested third parties - are expensive, resource intensive and time consuming. It takes a considerable amount of effort to support an audit including preparations - gathering supporting materials as evidence, conducting background checks (audited information may be sensitive and classified), planning and scheduling the event, orchestration of travel and establishing the meeting time and place; the effort is extensive. In my own experience, having conducted several limited scope security audits has taken me upwards of several months - for just one customer.
Further, an audit typically provides not just a discussion of security controls, but requires proof through the gathering of material evidence. During an audit the CSP is expected to state what are the security controls and measures implemented, and then provide actual evidence of their compliance through documentation, journals, service tickets and more. This requires that documentation, and in some cases attestation of the documentation implemented in operations be provided as the evidence. Any issues found must be remediated and reported as the issues are fixed.
SAP's acquired solutions such as SuccessFactors, Ariba and the like historically supported direct audits when they were smaller and independent of SAP. But since the acquisition of these line of business (LOB) solutions, this has become less practical. So SAP has changed its policy to support audits only when they are justified, which includes the following. This is outlined in current version of the Data Processing Agreement, which is part of the cloud subscription agreement.
So SAP does support direct audits when it makes sense to do so. But, routine annual audits are specifically excluded, simply because they are impractical.
Security Assessments vs. Security Audit
SAP supports (and encourages!) customer security assessments as a self-service function. A security assessment is different from a security audit whereas an assessment is an internally conducted evaluation of third party (i.e., SAP) controls and an audit is just that, a full scale on site audit involving auditors and supporting evidence resulting in a formal evaluation and opinion of security controls.
This one factor - gathering evidence - is the predominant factor in what differentiates an audit from an assessment, the former of which gathers a definitive list of controls and evidence as to compliance while the latter simply discusses the controls in practice. Yet, confirmation and attestation of compliance would still be valued. This is where the SOC reports come in.
So here's a thought.
Why not audit the cloud service once, and share the report with anyone who has such an interest? That's smart; a good idea. And, SOC for Service Organizations is precisely what the AICPA and the AIA has proposed and describes.
SOC Reports and SSAE Attestation Promote Transparency
SOC reports, according to the AICPA "are designed to help service organizations that provide services to other entities, build trust and confidence in the service performed and controls related to the services through a report by an independent CPA."
In this context, SSAE attestation audits create an assertion - an opinion, if you will - of SAP's hosting practices. According to the AICPA, the "Purpose of the Engagement and Premise on Which an Attestation Engagement Is Conducted" is outlined in its Attestation Standards:
What this means is, an audit team from SAP's auditors will evaluate SAP's hosting practices and issue a SOC report, and customers may evaluate the SOC reports as part of their assessment. This fundamentally eliminates the need to audit the CSP directly as it is done on behalf of our customers. Also not that as part of our practice, SAP funds the report and therefore bears the cost of the audit exclusively - which I add, is considerable. All of our attestations and certification are provided without additional cost to our customers.
SAP's auditors are currently PWC (Price Waterhouse Coopers) and we produce SOC 2 Type 2 reports twice annually.
For Cloud offerings, SOC reports incorporate one or more of the Trust Service Principles which include Confidentiality, Integrity, Availability, Information Security and Data Privacy.
There are several types of SOC reports. Each has a different purpose and it probably makes sense to mention what they are and what they do.
These reports are designed to meet the needs of users who need assurance about the controls at a service organization relevant to security, availability, processing integrity confidentiality, or privacy, but do not have the need for or the knowledge necessary to make effective use of a SOC 2 Report.
Further, there are also two sub-types of each of the above report. The "type" of the report is added to the end of name, such as SOC 2 Type 2.
SAP Customers that periodically review a SOC report receive valuable information regarding SAP's controls and the effectiveness of those controls. Customers receive a detailed description of the service organization's controls and an independent assessment of whether the controls were placed in operation, suitably designed, and operating effectively (in the case of a Type II report).
Addition notes on SOC reports include the following.
SOC reports are self-service and available in the SAP Cloud Trust Center (under Compliance | Search for a Report). PWC owns the reports and prepares a custom report for each customer. Also know that this is a manual process and the process is sometimes slow.
What About Security Questionnaires?
SAP will complete security questionnaires and/or requests for information/proposals (RFx) during a solution evaluation - prior to a sale - to provide a baseline foundation and orientation of security and hosting practices to the customer. Thereafter, new security questionnaires are considered a form of direct audit and are generally not accepted unless justified according to the above criteria.
Why?
The simple reason is, they are inefficient, redundant to other information already provided and not recognized as appropriate for ongoing evaluations of a Cloud Service Provider (CSP) by the cloud computing industry in general. Instead, the industry has created the SSAE Attestation standard with the expectation that customers would rely first on the SOC reports, any ISO certifications, and other publicly available information to be used as a self-service function to complete their periodic annual security assessments.
But security questionnaires can simply be updated very easily by incorporating change notifications.
Consider that SAP provides change notifications to our customers for material changes to the service. After a sales cycle and upon procurement of any SAP Cloud solution, SAP will provide notification of material changes to the service. This is even stipulated in the subscription Agreement. According to the General Terms and Conditions of the subscription Agreement, (currently § 3.4 Modifications):
Customers are therefore asked instead to rely on the SSAE attestation, certifications and resulting SOC reports published on SAP.com, as well as information provided in the Cloud Security Framework in the SAP Trust Center, and there is a wealth of information in the SAP Trust Center.
Customers can therefore rely on the sum total of:
Note that SAP customer support will not accept security questionnaires and they should not be submitted to SAP support channels.
My Top 10 List of Sources of Information Available for Evaluation
There a number of sources of information that we provide, some of which were outlined above. These are the resources that I would propose that customers visit to gather the supporting information they require.
Summary and Conclusion
SAP understands the needs of our customers and respects the requirement for transparency and reasonable assurances that our cloud-based solutions will protect their data.
We provide a wealth of information available to both customers and prospective customers for your evaluation. We want to be your partner and Cloud Service Provider of choice, and we want nothing but the best experience for you.
I sincerely hope this has helped, as there is a lot of information here, and I covered a lot of ground.
Contact your SAP Account Executive for additional information.
____________________
1 Adam Gordon, The Official (ISC)2 Guide to the CCSP CBK. © 2016 John Wiley & Sons, Inc. Second Edition.
2 IAPP, European Data Protection, Law and Practice, © 2018, IAPP.
3 AICPA, Information for service organization management, © 2018 Association of International Certified Professional Accountants
***
The content presented herein represents the opinion of the author and does not necessarily represent the formal policy or practices of SAP. This presentation is not subject to your license agreement or any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or any related document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality. This presentation is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation is for informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this presentation, except if such damages were caused by SAP’s intentional or gross negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
a weblog, by Mark S. Ciminello, MBA, PMP, CISSP, CCSP
updated March 5, 2020
Mark Ciminello is SAP’s Principal Engineer for Cloud Security in the domains of Cloud (hosting), InfoSec, Data Privacy, Legal and Regulatory Compliance within the SAP Global Security organization. He lives in the Phoenix area and has been with SAP since 2010, bringing well over 35+ years of experience in Project Management, Information Security and Cloud.
I must get this one request from nearly every customer I talk to: "We want to be able to audit SAP as needed and want SAP's cooperation and support."
As a Certified Cloud Security Professional (CCSP), I understand the ask. I get that customers need to keep an eye on the ball and I see that as a good thing, one that is a smart ask from the customer. If I were in their shoes I would want the same thing. In fact, I would require it. I would require my cloud provider to support my diligence and would likely not enter into any contractual obligation or certainly not a business partnership with the provider unless they agreed to promote transparency and provide assurances of reasonable and appropriate security controls. To me, this is paramount to the relationship; I would expect nothing less of my provider.
The CCSP credential recommends the practice of transparency through audits.
"In cloud relationships, where the ownership of the control that addresses the cloud risks resides within the CSP [Cloud Service Provider], organizations need to assess the CSP controls to understand if there are gaps within the expected cloud control framework that is overlaid between the cloud customer and the CSP." (1)
Further, within the Data Privacy industry, the Industry Association of Privacy Professionals (IAPP) also recommends the same.
"Part of the contracting should also include a suitable framework for ongoing assurance. These measures can range from the performance of on-site audits, inspections and testing to the provision of periodic assessments of ongoing compliance." (2)
But SAP is a very large Cloud Service Provider (CSP) and there are certain challenges and problematic logistical issues for us, as SAP customers increasingly move to the cloud. Further, as SAP now partners with the hyperscalers such as Microsoft (Azure), Amazon (AWS) and Google (Cloud Platform), this promotes an exponential factor in cloud-based revenue for SAP.
As such, I wanted to share some of my thoughts on the logistics of the issue, and provide some practical insights as to how SAP customers can keep an eye on the ball while not falling asleep at the wheel, then offer some guidance as to how they can get the information they need to do their diligence - from someone within the SAP organization.
Auditing the SAP Cloud (including hyperscalers)
For customers, security audits are the expected method of managing and monitoring the CSP/customer relationship. For small cloud companies that only have a few customers, a few hundred or even a few thousand, this is quite manageable. They have the resources and the wherewithal to support limited scope audits, the volume of requests is easily scalable and if the cloud supplier is exceptionally hungry to acquire new business (typically ignoring cost and feasibility), they agree to support them. But note that it may have long term consequences for execution as a cloud provider grows.
As I write, SAP has grown to more than 450,000 customers. This presents a logistical challenge to SAP to accommodate the audit needs of that many customers. What would happen if all of them needed to audit SAP?
Not surprisingly, this position and the recognition of scalability for CSP's is supported by both the AICPA (American Institute of Certified Public Accountants) and the AIA (Association of International Accountants). Both professional organizations recognize the unique aspects of cloud computing and cloud service providers, and understand the problems of scalability of CSP audits. The recommendation of both organizations is that Service Organization Controls reports (SOC) be leveraged instead - more on that below.
So now you ask, what about transparency? Accountability? Assurances? We need the ability to audit SAP when it makes sense to do so.
SAP agrees.
SAP does support direct audits, and agrees to cooperate with our customers.
SAP Supports Direct Audits
SAP supports direct audits when they are warranted and justified. SAP has constrained the use of direct audits however, to justifiable validity, as audits - involving SAP, customers, auditors or other interested third parties - are expensive, resource intensive and time consuming. It takes a considerable amount of effort to support an audit including preparations - gathering supporting materials as evidence, conducting background checks (audited information may be sensitive and classified), planning and scheduling the event, orchestration of travel and establishing the meeting time and place; the effort is extensive. In my own experience, having conducted several limited scope security audits has taken me upwards of several months - for just one customer.
Further, an audit typically provides not just a discussion of security controls, but requires proof through the gathering of material evidence. During an audit the CSP is expected to state what are the security controls and measures implemented, and then provide actual evidence of their compliance through documentation, journals, service tickets and more. This requires that documentation, and in some cases attestation of the documentation implemented in operations be provided as the evidence. Any issues found must be remediated and reported as the issues are fixed.
SAP's acquired solutions such as SuccessFactors, Ariba and the like historically supported direct audits when they were smaller and independent of SAP. But since the acquisition of these line of business (LOB) solutions, this has become less practical. So SAP has changed its policy to support audits only when they are justified, which includes the following. This is outlined in current version of the Data Processing Agreement, which is part of the cloud subscription agreement.
5. CERTIFICATIONS AND AUDITS
5.1 Customer Audit. Customer or its independent third party auditor reasonably acceptable to SAP (which shall not include any third party auditors who are either a competitor of SAP or not suitably qualified or independent) may audit SAP’s control environment and security practices relevant to Personal Data processed by SAP only if:
(a) SAP has not provided sufficient evidence of its compliance with the technical and
organizational measures that protect the production systems of the Cloud Service through
providing either: (i) a certification as to compliance with ISO 27001 or other standards (scope as defined in the certificate); or (ii) a valid ISAE3402 and/or ISAE3000 or other SOC1-3 attestation report. Upon Customer’s request audit reports or ISO certifications are available through the third party auditor or SAP;
(b) A Personal Data Breach has occurred;
(c) An audit is formally requested by Customer’s data protection authority; or
(d) Mandatory Data Protection Law provides Customer with a direct audit right and provided that Customer shall only audit once in any twelve month period unless mandatory Data Protection Law requires more frequent audits.
So SAP does support direct audits when it makes sense to do so. But, routine annual audits are specifically excluded, simply because they are impractical.
Security Assessments vs. Security Audit
SAP supports (and encourages!) customer security assessments as a self-service function. A security assessment is different from a security audit whereas an assessment is an internally conducted evaluation of third party (i.e., SAP) controls and an audit is just that, a full scale on site audit involving auditors and supporting evidence resulting in a formal evaluation and opinion of security controls.
This one factor - gathering evidence - is the predominant factor in what differentiates an audit from an assessment, the former of which gathers a definitive list of controls and evidence as to compliance while the latter simply discusses the controls in practice. Yet, confirmation and attestation of compliance would still be valued. This is where the SOC reports come in.
So here's a thought.
Why not audit the cloud service once, and share the report with anyone who has such an interest? That's smart; a good idea. And, SOC for Service Organizations is precisely what the AICPA and the AIA has proposed and describes.
SOC Reports and SSAE Attestation Promote Transparency
SOC reports, according to the AICPA "are designed to help service organizations that provide services to other entities, build trust and confidence in the service performed and controls related to the services through a report by an independent CPA."
In this context, SSAE attestation audits create an assertion - an opinion, if you will - of SAP's hosting practices. According to the AICPA, the "Purpose of the Engagement and Premise on Which an Attestation Engagement Is Conducted" is outlined in its Attestation Standards:
".07 The purpose of an attestation engagement is to provide users of information, generally third parties, with an opinion, conclusion, or findings regarding the reliability of subject matter or an assertion about the subject matter, as measured against suitable and available criteria. (An examination engagement results in an opinion; a review engagement results in a conclusion; and an agreed-upon procedures engagement results in findings.) The practitioner’s report is intended to enhance the degree of confidence that intended users can place in the subject matter."3
What this means is, an audit team from SAP's auditors will evaluate SAP's hosting practices and issue a SOC report, and customers may evaluate the SOC reports as part of their assessment. This fundamentally eliminates the need to audit the CSP directly as it is done on behalf of our customers. Also not that as part of our practice, SAP funds the report and therefore bears the cost of the audit exclusively - which I add, is considerable. All of our attestations and certification are provided without additional cost to our customers.
SAP's auditors are currently PWC (Price Waterhouse Coopers) and we produce SOC 2 Type 2 reports twice annually.
For Cloud offerings, SOC reports incorporate one or more of the Trust Service Principles which include Confidentiality, Integrity, Availability, Information Security and Data Privacy.
There are several types of SOC reports. Each has a different purpose and it probably makes sense to mention what they are and what they do.
- SOC 1®, SOC for Service Organization: ICFR (internal controls over financial reporting). Used for supporting financial audits. A SOC 1 evaluates a Service Organizations impact on an organizations financial statements.
- SOC 2®, SOC for Service Organizations: Trust Services Criteria. These reports are designed to provide detailed information relevant to security, availability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems.
- SOC 3®, SOC for Service Organizations: Trust Services Criteria for General Use Report.
These reports are designed to meet the needs of users who need assurance about the controls at a service organization relevant to security, availability, processing integrity confidentiality, or privacy, but do not have the need for or the knowledge necessary to make effective use of a SOC 2 Report.
Further, there are also two sub-types of each of the above report. The "type" of the report is added to the end of name, such as SOC 2 Type 2.
- A type 1 is state-based, meaning, it is a report as of a particular point in time.
- Type 2 is period-based, and is a report over a certain period of time. In the case of SAP, our audit cycles are April and November, so reports would be for 6-month periods.
SAP Customers that periodically review a SOC report receive valuable information regarding SAP's controls and the effectiveness of those controls. Customers receive a detailed description of the service organization's controls and an independent assessment of whether the controls were placed in operation, suitably designed, and operating effectively (in the case of a Type II report).
Addition notes on SOC reports include the following.
- SOC 1 is for live Customers only. Customers may request a SOC 1 Type 2 report only after the implementation of a live, productive system that could potentially have an impact on their financial condition.
- SOC 2 Type 2 is the main evaluation report. The SOC 2 Type 2 report provides a listing of the security measures and controls, and provides the greatest value to SAP customer for transparent evaluation of SAP's Cloud services.
- NDA is Required. An NDA must be in place for both the SOC 1 and SOC 2 reports.
- SOC reports are owned by the auditors. SOC reports are actually owned by the auditors (in this case PWC), and not SAP. PWC will therefore control the distribution and an NDA must be in place for SOC 1 or 2, while a SOC 3 is a generalized report and may be freely distributed.
- Audit Cycles. Our audit cycles are April and November. SOC reports would generally be available 30-60 days after the close of the audit period. Bridge letters are created and available to bridge time gaps if the report is delayed for any reason.
SOC reports are self-service and available in the SAP Cloud Trust Center (under Compliance | Search for a Report). PWC owns the reports and prepares a custom report for each customer. Also know that this is a manual process and the process is sometimes slow.
What About Security Questionnaires?
SAP will complete security questionnaires and/or requests for information/proposals (RFx) during a solution evaluation - prior to a sale - to provide a baseline foundation and orientation of security and hosting practices to the customer. Thereafter, new security questionnaires are considered a form of direct audit and are generally not accepted unless justified according to the above criteria.
Why?
The simple reason is, they are inefficient, redundant to other information already provided and not recognized as appropriate for ongoing evaluations of a Cloud Service Provider (CSP) by the cloud computing industry in general. Instead, the industry has created the SSAE Attestation standard with the expectation that customers would rely first on the SOC reports, any ISO certifications, and other publicly available information to be used as a self-service function to complete their periodic annual security assessments.
But security questionnaires can simply be updated very easily by incorporating change notifications.
Consider that SAP provides change notifications to our customers for material changes to the service. After a sales cycle and upon procurement of any SAP Cloud solution, SAP will provide notification of material changes to the service. This is even stipulated in the subscription Agreement. According to the General Terms and Conditions of the subscription Agreement, (currently § 3.4 Modifications):
"(a) The Cloud Service and SAP Policies may be modified by SAP. SAP will inform Customer of modifications by email, the support portal, release notes, Documentation or the Cloud Service. The information will be delivered by email if the modification is not solely an enhancement."
Customers are therefore asked instead to rely on the SSAE attestation, certifications and resulting SOC reports published on SAP.com, as well as information provided in the Cloud Security Framework in the SAP Trust Center, and there is a wealth of information in the SAP Trust Center.
Customers can therefore rely on the sum total of:
- Their initial understanding of SAP practices provided during a sales cycle and incorporated into any security questionnaire or RFx
- The incorporation of all material change notices provided by SAP Cloud
- Information provided on SAP.com and the SAP Cloud Trust Center
- Individual questions submitted via service ticket through SAP ONE Support
Note that SAP customer support will not accept security questionnaires and they should not be submitted to SAP support channels.
My Top 10 List of Sources of Information Available for Evaluation
There a number of sources of information that we provide, some of which were outlined above. These are the resources that I would propose that customers visit to gather the supporting information they require.
- SAP Cloud Trust Center. SAP has built the SAP Trust Center to provide information on SAP security practices including its cloud offering, data privacy and protections.
- SOC reports. SOC 1 and SOC 2 reports are self-service and available in the SAP Trust Center Compliance Finder. PWC owns the reports and will distribute the reports. An NDA must be in place prior to request.
- Certifications. SAP maintains ISO, British Standard (BS) certifications and makes those available in the SAP Cloud Trust Center.
- Security Questionnaires/RFx. We support security questionnaires and will complete those during a sales cycle.
- Change Notifications. SAP will provide sub processor lists and notification changes for changes made to the service. Also available are SAP Roadmaps, which provide a 12-month rolling cycle of planned enhancements by solution.
- CSA CAIQ. Most of our major suites have completed CAIQ (Consensus Assessment Initiative Questionnaire) from the Cloud Security Alliance. Although we do not publish our security practices and make them available publicly, you can request a CAIQ through your SAP Account Executive. Have them reach out to their presales team and we will find the relevant document for you.
- Cloud Security and related whitepapers. Most SAP customers will get these during their initial evaluation. Many provide considerable detail on SAP's security practices. Most customers find these documents to be generally adequate.
- ISO Standards. SAP is fundamentally aligned to international standards and specifically the ISO 27000 family of standards, but also takes guidance from other relevant standards such as NIST SP 800-53, British Standard BS 10012 and more. If we are aligned to these standards then those standards outline the basis of our security practices.
- SAP Roadmaps. SAP provides a rolling 12-month cycle of roadmaps that provide a list of functional and technical changes by solution. The roadmaps are published on SAP.com as SAP Product and Solution Roadmaps.
- SAP, SAP.com, Financials, Sapphire and Tech Ed. SAP is a public company. We are required to perform SEC filings, and we provide updates on what SAP is thinking, our strategy, vision, and how we see software for the enterprise. We publish this information and conduct global events at Sapphire - SAP's user group (ASUG), and at Tech Ed.
Summary and Conclusion
SAP understands the needs of our customers and respects the requirement for transparency and reasonable assurances that our cloud-based solutions will protect their data.
- SAP agrees to support audits under select conditions, when they are justified and make sense to do so. Annual security questionnaires post-sale are not in line with industry standards and are supported only as a self-service function.
- Security assessments are different than direct audits, and SAP provides the supporting materials for self-service assessments.
- Customers may leverage SOC reports, solution certifications, their own internal initial security questionnaires or RFx (completed during a solution evaluation) and the sum total of all change notifications from SAP as their primary means to conduct routine assessments.
- Additional questions or concerns not addressed through the above procedures may be submitted through standard support procedures.
We provide a wealth of information available to both customers and prospective customers for your evaluation. We want to be your partner and Cloud Service Provider of choice, and we want nothing but the best experience for you.
I sincerely hope this has helped, as there is a lot of information here, and I covered a lot of ground.
Contact your SAP Account Executive for additional information.
____________________
1 Adam Gordon, The Official (ISC)2 Guide to the CCSP CBK. © 2016 John Wiley & Sons, Inc. Second Edition.
2 IAPP, European Data Protection, Law and Practice, © 2018, IAPP.
3 AICPA, Information for service organization management, © 2018 Association of International Certified Professional Accountants
***
The content presented herein represents the opinion of the author and does not necessarily represent the formal policy or practices of SAP. This presentation is not subject to your license agreement or any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of business outlined in this presentation or any related document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice. The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or functionality. This presentation is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation is for informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions in this presentation, except if such damages were caused by SAP’s intentional or gross negligence.
All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.
- SAP Managed Tags:
1 Comment
