Why Procurement Practitioners Need a New Provider Bill of Rights, Part 2 (The Challenge) Pierre Mitchell - October 22, 2013 9:56 AM | Categories: Procurement Commentary, Procurement Strategy & Planning, Solution Providers | Tags: Incendiary Tidbits, L1 In Part One of this series, we discussed the need for a procurement solutions “Bill of Rights” and covered the first right: the ability to de-couple the procurement applications and the supplier networks that they connect to. We’ll now cover another. Right #2 – Have your mission critical B2B data be secure. This seems like a no-brainer, right? However, it’s easy to support in principle and much harder to do in practice. Let’s start with security. Provider support for SAS 70 and ISO 27001 can be just table stakes. Various industries have their own particular security standards. For example, in A&D, the International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR) prohibit data pertaining to certain sensitive products from being sent over the Internet and stored on servers outside the US. I recently found a terrific superset list of generic cloud computing security requirements and how they map to various regulations and standards. Check out the following spreadsheet from a nonprofit called the Cloud Security Alliance. It not only maps which ones affect service providers (see column under “supplier relationship” section), but also has an entire section on “Supply Chain Management, Transparency and Accountability” with third party management requirements surrounding the following: Data Quality and Integrity; Incident Reporting; Network / Infrastructure Services; Provider Internal Assessments; Supply Chain Agreements; Supply Chain Governance Reviews; Supply Chain Metrics; Third Party Assessment; and Third Party Audits. The spreadsheet is not all encompassing in terms of industry-specific requirements, but it is a great start. For many of these security regulations, there are very specific requirements not only for strong user authentication at the top of the technology stack and low-level infrastructure security requirements at the data center, hardware, operating system, and database level, but also data and process level security such as strong message encryption, including encryption of sensitive documents that support a transaction. This could be patient specific information in healthcare or specific intellectual property (IP) surrounding a product or the supply chain. For example, PIDX is a standard in the oil and gas industry that has very specific security and data confidentiality requirements. While you may roll your eyes at the degree by which PO and invoice data is strategic IP, some of the supporting documents needed to pay third parties performing energy exploration work can contain highly sensitive information. In other industries such as Financial Services / Insurance, Media & Entertainment, Public Sector, IT/Telecom, etc., you can imagine how such stringent security is critical to protect confidentiality, the corporate brand, and even the safety and well being of the process participants themselves. Given this criticality, procurement and supply chain application providers must either support these requirements natively or find technology providers who can provide such mission-critical security, integration, participant onboarding, etc. If the application provider offers a business network, it is even more important to support these industry-specific requirements by offering a message to integrate such data security and confidentiality into the network infrastructure itself. Of course, such support is often complex and not well suited to the commercial models of the business networks themselves. In other words, providing support for transmission of encrypted information that only the trading partners retain may be par for the course for an infrastructure firm like IBM / Sterling Commerce, but may not be attractive to the provider that seeks to monetize process automation based on the content of the information payload (e.g., charging suppliers based on a percentage of invoice value rather than the volume of the invoices and other transactions). For example, we have spoken with a few practitioners who are having difficult conversations with SAP not just because of the blowback of supplier-funded process integration, but also because of these data security and confidentiality issues. This could cost Ariba/SAP dozens of potential agreements unless the provider changes its policy regarding data security. Next we'll turn our attention to Ariba and SAP, who appear to be setting themselves up in opposition to a Provider Bill of Rights in this area – and how specifically they are doing so in certain industries. Discuss this: Cancel reply Your email address will not be published. Required fields are marked *Comment Name * Email * Website Notify me of follow-up comments by email. Notify me of new posts by email.