When changes are made to your system, it's important to consider and communicate any InfoSec related implications.

The communication of changes can be critical from both a customer success, and an information security perspective. But they’re often often done in an ad-hoc and inconsistent way. In the earlier stages of your business, you have less users, less permutations of how your product(s) are used, and more closely managed customer relationships. That means less importance of a formal process for communicating system changes.

But as your user base grows, your product(s) are used in a wider variety of ways, and you rely on a broader services team to support your customers. Release notifications that update your users on the changes become increasingly important.

The customer success angle to these comms is more obvious; if you’re changing the system you want to ensure it doesn’t adversely impact current users. You should help them adjust to any changes that do impact them. Perhaps most importantly, you want your customers to use new features to get the most value out of your services.

There’s two primary purposes of release communications from an InfoSec perspective;

1. Help users to understand any changes that may give rise to new vulnerabilities or risks in the way they use your services; and
2. Learn about new features that can improve their security practices;

The importance of this InfoSec angle is often overlooked. It may seem obvious. Or like it’s solely the users responsibility. Or perhaps because it’s a less direct connection to information security than the likes of a security policy or technical controls like authentication and encryption. But that doesn’t mean it’s any less important, and arguably can be more important. Security failures are more-often-than-not due to the “human element” (people failures) rather than technical security weaknesses.

The other challenge with communications of changes; it’s often ambiguous what the impact is, or may be. You don’t want to spam your users with details of every change. It can be difficult to have complete awareness of how users use the system and where there may be sensitivities associated with that.

Example changes with InfoSec implications

If you’re wondering what sort of changes have InfoSec implications, here’s a few categories/examples:

• Data sharing functionalities: Any new or changed function that enables users to collect, process, and share data, can have InfoSec implications. If you add a new data type, or just the way the data is shared, that may have implications for your users privacy, confidentiality and security practices. For example, when Google released Google Docs and particularly with link sharing, enterprises needed to consider the increased risk of data leakage from its employees storing documents and data in the cloud and being able to easily share it with others.
• Security configurations and settings: any changes to the system configurations and settings may require a re-evaluation by users. Eg. if you allow new integrations with other products, or change the default or systematically enforced password parameters, it may no longer meet end-users security requirements. Or the change may give an opportunity to strengthen their security practices, which is important for the continual improvement of security.
• User access and functionalities: users roles and access within a system should be configured to 'least privilege access'. That requires an understanding of the access by the users administrators to apply it. If you add a new functionality, or change the nature of access privileges, it can impact that least privilege and may require changes to the access rights of users accordingly. For example, if you add a new reporting feature that visualises the data stored in the system, who should be able to see those reports and what data should they be able to access as part of that?
• System usage specific changes: This is a ‘catch-all’ category recognising that each system has a different purpose and design. InfoSec is relevant in different ways accordingly. Functions that may seem irrelevant to security can be when put into practice by the end-users. For example, in a workflow automation platform where a user can define their own workflows. If a change is implemented to allow users to assign other users to their workflow as part of the design. The users are then performing a pseudo-admin role where they can add other users access to what’s contained in that workflow. That may give access to sensitive content that shouldn’t be shared unless the assigned users have been appropriately authorised.

What change control practices address user communications?

Change impact assessment

Not every change will have information security implications, but it’s important to have an impact assessment to determine whether there might be any. If in doubt, the changes should be communicated to your users system admins, account owners or other responsible owners of the services to consider. And if there are security implications, it’s important to ensure they are communicated to the right people that need to assess that, or take some other action(s) accordingly. That’s often a system admin but can be specific user types or the customers vendor risk management team.

Release notes

It’s a good practice for customer success and InfoSec, to have general release notes made available to all users and internal employees. That gives some awareness and a paper trail to look back on as needed. If something operates in unexpected ways they can look into the release notes or follow up with the product development team accordingly by having that awareness of the change history. There’s various solutions out there that may release notes easy like Atlassian JIRA and BuildKite for example.

Product tool-tips

An increasingly common practice is tooltips for “what’s new” inside the product. This helps turn release notes into a more pragmatic illustration of what’s actually changed, which helps users understand those changes better in practice.

Bespoke Communications

As part of your broader information and communications strategy, you will hopefully have good customer records of the types of users you are supporting. Depending on the nature of your service or platform, it might include an overall sponsor or account owner, system administrators, general users, and perhaps a range of other specific functions that fit your product, eg. In a no-code development platform you might have “app builders” and “testers”. When functions change that impact a particular user type, or should otherwise be made known to a particular type of user, there should be specific communications to those people accordingly. For example, if the terms and conditions of your service change, then the account owners or sponsors should be made aware. If the system settings or configurations change, the system administrators should be made aware.