Customer communications may sound like an obvious and simple concept; but it's not. It often breaks down in practice.
In the earlier stages of a company, communications may be handled in a less defined way with the senior management team taking ownership of it directly. As the company grows, it becomes increasingly important to have clearly defined and operated practices to ensure complete and effective communication.
For businesses reading AssuranceLab's website, it's likely you've figured out the sales, marketing and onboarding communications required to obtain customers. This post is more focused on where you support enterprise businesses and the types of communications necessary at that scale. Often these formal and defined practices are revised or even implemented for the first time as part of a SOC 1, SOC 2 or ISO 27001 implementation. SOC 2 in particular places a lot of emphasis on this area.
The really important context here, is that enterprise customers may have hundreds or even thousands of their employees using your product or service. They're likely to have hundreds or thousands of other service providers, each providing different services and managed in different ways. They need to manage all these services effectively across all of their users, which can be incredibly difficult at that scale.
It's important for service providers to clearly articulate the terms of service, operation of the system, and any changes or issues that occur. That enables them to manage their own environment and use of your service effectively. They hold direct responsibilities like what data they store or use in your product and managing users and configurations (as applicable).
What customer communications are important and necessary?
Defined Responsibilities and Terms
The statement of work, master services agreement, standard terms of service, or whatever documented agreement sets out the terms of your services. This should clearly set out responsibilities; including where the users of the service need to perform certain functions to protect the integrity and security of the services. For example, for many software services, it's the customers responsibility to manage their own users access to the software and configuration settings such as the minimum password requirements and whether API's and integrations are allowed. It's all well and good if you communicate these sorts of considerations to the customer sponsor, account manager or administrator of your services, but it leaves a grey area of liability if not formally agreed, and also creates challenges for enterprises to clearly track their responsibilities across all services.
The Operation of the System
The system in this context may be a product and/or services. The operation of the system is the way it works in practice. For software services, this is often set out in system diagrams, knowledge base, user guides, administration guides, tooltips within the software, training modules, and communicated as part of onboarding and ongoing customer success support. The purpose of these communications is to ensure users of the system have a clear understanding of how it works.
Communicating the operation of the system is highly relevant to information security. Security breaches are often the result of lacking this understanding where data is inadvertently disclosed to the wrong people. For example, Google Sheets is a product that enables easy sharing of spreadsheets through the cloud. If users aren't aware of the way link sharing works or the security settings applied to the sheets, then they may accidentally share it with the wrong people. Another common example is not understanding what system access privileges provide to the user, and can give them more access than what was intended.
The best practice for service providers, is to perform a risk assessment of where incorrect usage of the system may undermine the security or integrity of the system or data. Putting in place safeguards, warnings or further guidance and highlighting these to users can help achieve better security outcomes; or at least avoid negative outcomes!
Service Changes or Issues
It sounds like a no-brainer that users of the system should be told when things change, or there are issues. Surprisingly, this is not well handled in practice by many businesses. Modern agile businesses are especially prone to the focus on rapid change to continue improving their products and services. However, often they lack focus on how these changes are communicated to customers. Similar to the concepts discussed above, this can undermine the security, integrity and end-users ability to effectively manage their own use of the products and services.
There's a balancing act when it comes to change communications; users don't like to be spammed. Equally, users don't like surprises when the system or services operate differently to what they expected. The most common way to handle change communications is to send a release notification to users so they are aware of what changes are going to be, or have been, implemented. That may include minimal detail and be subject to subscription, opting in or out.
Information Management
There's a broader topic that we cover in our Information & Communications Checklist, which is how to collect the right information to support broader communication practices. That includes logging incidents, changes, usage logs, customer account info, SLA data, security events, failed logon attempts and potentially many other areas. Having this data enables you to communicate with your customers in a more meaningful and effective way. That may not always be proactive communication, but triggered from your customers seeking information about their use of the system and what's relevant to them.
The SOC 2 Perspective
For SOC 2, there’s two criteria related to customer communications. The first is about collecting quality information to support all other processes, monitoring and performance. The second is about external communication with third parties, in particular customers and end users of the system.
COSO Principle 13: The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
COSO Principle 15: The entity communicates with external parties regarding matters affecting the functioning of internal control.
AssuranceLab's Best Practices Series
AssuranceLab's best practices series, is about highlighting the "real operational benefits" that comes from effective control practices. At best, they support your company culture, provide structure and clarity, and enable scalable growth. At worst, they ticks the box of what your customers expect, reduce the reactive "firefighting" and time-wasting, and help you demonstrate your compliance with leading standards like SOC 2 and ISO 27001.