Takeaways from the IBSMA Compliance Manager Summit
Take note of how the GDPR may affect software audits once the regulation comes into force; ensure full understanding of open source software licensing and compliance; and provide clarity around enforcing and responding to audits were key points of discussion at this week’s IBSMA conference.
I’ve just spent two days in San Francisco at the IBSMA Compliance Manager Summit. In addition to speaking at this event, I had plenty of opportunity to attend other sessions and network with the other attendees. Here’s my key takeaways from the sessions I attended (none of them related to either vendor-specific licensing or Software Asset Management (SAM) Solutions):
FOR SOFTWARE VENDOR
- The GDPR & software audits. Under the new EU legislation much of the data collected as part of an audit will be considered personal data, so mechanisms will have to be put in place to ensure that the data collected as part of an audit is managed appropriately. Software vendors will have to justify the collection of detailed data, rather than collecting as much detail as possible by default.
- Open source software. You need to ensure that all open source software components within your software are clearly identified and that the license terms and conditions are complied with before releasing the product commercially.
- Audits & compliance programs. More work is needed to clearly differentiate audits, compliance activity and SAM activities (where SAM data is being used to make business decisions including true-ups, cloud shifting etc.) for vendors’ customers. While the first two are understandably conflated, it is a concern that the last is still perceived as being ‘audit’. While I would always advise that any activity that involves sharing data with a third party (vendor, auditor, business partner) has appropriate processes and controls around it, there is a difference between compliance exercises and enabling activities such as cloud readiness & security assessments or optimization assessments. However, there are perception issues persist and vendors need to work harder to get customers to understand the differences. With many of these activities reporting into, or being associated with, compliance teams may be part of the problem. While the way in which many vendors deal with compliance has evolved and matured, there is still a significant gap in the trust between customers and vendors when it comes to SAM.
FOR END-USER ORGANIZATIONS
- The GDPR. Personal data and the GDPR should be considered when collecting data for SAM purposes and in particular, for audits, where data will be transferred out of the organization. Ensure that you understand the data you are collecting and understand the GDPR implications of this data and put the appropriate control mechanisms in place. Review your audit management processes to ensure that both vendors and auditors acting on their behalf are complying with the GDPR in the way that they process your data.
- Open source software. There are significant risks with open source software and free open source software, and the code licensed in this way that is likely to be embedded in software throughout your organization. Before buying such software, ensure that the contract requires the vendor to identify and list open source software components and takes on the liability for any license infringement. Although contractual responsibilities around this seem a last resort, the sensible option when looking at new software is either to ask the vendor for certification from an independent third party that the open source software components are correctly identified and licensed, or to require them to submit to an audit of the code by a third party.
- Audits. Ensure that processes and procedures are in place, particularly those around of data and ensure security and risk management (and a data protection representative) are involved in designing the rules and controls around the collection and sharing of data. Understand the different types of audits and the way in which different vendors approach them (both in process terms and in terms of their commercial approach). Don’t rely on your previous experience of audits (even audits by the same vendor) to inform this – go out and do your research, ask questions and find out what the current approach is.
- General SAM and ITAM issues. To remain relevant in an age of digital disruption we need to think carefully about the scope of ITAM. There’s a lot of discussion in the industry about terminology, and this is what is constraining us at times. We need to think about WHY we are doing what we are doing and consider how what we do may need to change to keep us relevant. Crucially ITAM needs to position itself as governance of technology assets rather than being focused primarily on licensing detail. If we get the governance and process right, then we can automate much of the detail and save our attention for the exceptions that flag up risks and opportunities for us. The scope of ITAM needs to be kept tight to give us a chance to succeed. Rather than taking on additional responsibilities we should be working to provide a framework, processes and tools that enable people to make effective business decisions about the assets they manage and drive accountability outwards.
- ISO 19770 There’s a lot more work being done by Working Group 21, including some useful material on mapping ISO 19770-1 to other standards and another document which will provide a guide to auditing for compliance to the standard. This is in addition to continuing to update the existing documents every five years.
Are you heading up the SAM practice in your organization? Why not download Snow’s new eBook of how to Address Real-world Challenges of Managing Software Assets.
