How does it affect my tenant? Questions to ask for Office 365/SharePoint solutions

I’m doing some Office 365 architecture work at the moment to ensure our clients have a clear view of our solutions and how they work. Any organisation working with a partner or deploying products based on Office 365 needs to ask “how does it affect my tenant?” – but of course, that’s just the high-level question. Underneath are a whole series of security, compliance, operational, cost and other governance considerations that should be explored for robust long-term successful use of Office 365. However, I find that many organisations don’t yet know how to ask the right questions or dig into the right areas – and this can lead to risks of compliance issues, data leakage, impact to organisational productivity or any number of other problems down the line.

So, I thought it would be good to share a starter checklist of topics and questions to ask related to solutions which extend Office 365 in some way. The focus is on SharePoint-based customisations, and it’s not a comprehensive list – you could certainly broaden the scope, or go deeper in specific areas by asking more questions. But hopefully my list gives a sense of the type of questions you should ask before accepting a solution into your environment, or on the other side, the kind of thing you should be providing as a trustworthy vendor/partner/internal development team in your documentation.

For larger enterprises, my work often involves more than documentation. Commonly, I’m walking various technical teams and service owners through the low-level detail of our solution, and each needs to grant approval before our solution can pass. I’m currently working with one of the world’s largest companies, and we need around 10-12 teams to approve their respective bits, and then to also pass a “unity review” which considers the overall picture. I’m using a combination of PowerPoint and live demos on the conference calls with the respective teams, and it’s all about socialising the concepts and ensuring the low-level detail is covered and all questions are answered. I do think the onus is on the implementation team to proactively “push” the information – as noted earlier, in-house teams don’t always know the right questions to ask. If you have your client’s best interests at heart though, you’ll want them to be well-informed.

My suggested checklist

What does the overall architecture look like?

• Which Office 365 services are used?
• What does the architecture diagram(s) of your solution look like?

User data/user profiles

• Are any custom fields added to AAD profiles?
• Are any custom fields added to SPO profiles?
• How does data get into the fields? Is there a sync solution, or do users edit their values through native Office 365 or custom interfaces?

Security

• Are any changes to the “Custom script” settings proposed (i.e. is there any ad-hoc JavaScript running outside of modern pages and the SPFx security model)? HINT – you really want both of these set to “prevent” if possible:
  
  
  
  
• What SPFx permissions are required? (as shown on the Web API permissions page)?
  
  
  
  
• Are any AAD app registrations created (related to use of the Microsoft Graph API)?
  
  
  
  
  
  
• What 3rd party libraries are used by the solution? Can you show us a current npm audit report?
• What certificates are used by the solution?
• How are they managed and where are they deployed to?
• What is the expiry date of any certificates and how is rollover handled?
• If remote code elements are deployed (Functions or other web APIs), what authentication model is used?
• Are any code elements or artifacts *not* hosted in our tenants/subscriptions? If so, what purpose do they serve? How can we be sure our data isn’t passed to them?

Taxonomy

• What term groups and term sets are provisioned?
• How are they used/what purpose do they serve?
• Are they open or closed term sets?
• How are they identified? Will my users confuse them for something else?
• Are they a duplicate of something already in place?

Search configuration

• What new managed properties are provisioned?
• More importantly, are any mappings of existing out-of-the-box properties provisioned?
• How can I be sure any use of RefinableStringXX, RefinableDateXX, RefinableIntXX and so on don’t clash with existing mappings in use in my tenant?
• What result sources are provisioned?
• What other search configuration is provisioned?

Teams

• What aspects of the Teams dev platform are used (e.g. tabs, connectors, bots, messaging extensions)?
• What permissions/device permissions are used?
• What remote domains are used? What for?

Office Add-ins

• If Office add-ins are used, what are their permission requirements (e.g. “ReadWriteMailbox”)?
• Is Centralized Deployment used to deploy the add-ins? If not, why not?
• Which Office applications do the add-ins surface in?

Azure

• What is deployed to Azure? Is it just PAAS elements or are there any IAAS elements?
• If Azure Functions are used, are they on the Consumption Plan or App Service Plan?
• What are the forecast costs? What could vary this?

SharePoint content (see note below)

• What site types are used (e.g. communication sites, hub sites, team sites etc.)?
• Are any classic SharePoint elements used (e.g. classic publishing sites)

SPFx

• What SPFx packages are used?
• Which are deployed tenant-wide, and which are per site collection?
• [Also see Security section for considerations on SPFx security]

Notice that the list does not focus too much on SharePoint content. If the solution gets deployed into an existing SharePoint site collection (or several), you might ask questions about the content types and site columns and so on which are provisioned. In most cases however, what goes on within individual SharePoint sites is a lower-level concern where the risks are much lower (at least in SharePoint Online).

Summary

Successful use of Office 365 in the enterprise relies on balancing productivity and agility with security and governance, and part of this involves knowing exactly what’s in your tenant and how it works.

Just because you no longer own and manage the physical servers doesn’t mean that a breach isn’t possible or your data cannot be stolen. Office 365 is designed with customisation in mind (at least, it is these days) and there are many many security features which are designed to ensure that the platform can be extended in safe, governable ways. However, you do need to make sure that you use them - and I think it’s fair to say that some older vendor/product Office 365 solutions that haven’t been updated do not.

No doubt there are some useful products which can help with solution governance in this way, but I’m not sure any of them cover all of the aspects listed here. Hopefully this checklist can help!