In the excitement of rolling out Office 365 within an organization, Enterprise Risk is often the poor relation to Features, but it is much easier to handle if it is built into your program of work from the start. This blog post outlines a few common risk stakeholders that you will need to engage with as early as possible to ensure a smooth rollout. Obviously different organizations will have different terminology for these groups, but all will have leaders / executives who are responsible for these core areas.

How should I build this into an Office 365 delivery team?

Most successful Office 365 programs are run either as Agile projects (where business stakeholders are intimately involved in the deployment) or have a named individual who represents the “voice of the business” for the project team.

In the same way, you should have a named individual who is responsible for ensuring that the risk stakeholders’ voices are heard, and their needs are built into the project from the outset.

This advocate does not need to be a subject matter expert in all areas of risk, but they should be having regular reviews with risk stakeholders to ensure that the risk needs are met.

Who should this person be?

I have worked in teams where an Enterprise Architect is responsible for this, and in other teams where an engagement leader or program manager has taken this role. However, it should be someone who is able to engage with multiple risk leaders within your organization, and this should be their main role in the project.

What risk areas do I need to worry about?

Every organization will have different structures for managing risk, but broadly the following areas of risk need to be covered:

• Identity and Access Management
• Legal
  • E-Discovery / Legal Hold
  • Compliance with regulations [e.g. GDPR]
• Reputational risk / business risks [e.g. HR]
• Cyber security and data exfiltration prevention
• Operational support
• Change governance

You should keep a risk log, detailing all of the risks that have been identified, external frameworks such as SOC2 that demand this risk be mitigated, and how you intend to implement controls to reduce or eliminate the risk.

The controls you implement for each risks may include:

• Policies / terms of use
• Training
• Configuration / technical implementations of mitigations and controls
• Monitoring / alerting to specific behaviour
• Processes and sign-off criteria

What next?

Cloud SaaS solutions have a huge advantage to the business in the way that they rapidly update their features and add new capabilities. That does, however, pose a problem for risk management; as these features evolve, the risk position may be materially impacted. This means that you should build some capacity into your ongoing platform investment to keep risk leaders informed of change and to rapidly react to new threats.