This version of the security policy is applicable from august 2020.

Here we give the Customer a brief overview of the security measures we have taken, and how and why we will process the Customer’s data.

The Customer acknowledges that this overview is in no way all-encompassing, and that the measures we have taken are subject to change.

1. Storage

In the schema above we make a simple representation of the data flow of the GroupMgr. We are able to access certain services in your Office 365 environment. But we will only process data and store it in the customers tenant.

We do not keep / store any critical data outside the customers tenant.

We only store the following data in a SQL database:

  • Tenant ID (which is publicly available for anyone)
  • Encrypted UPN’s of users who are using our application (we need this to be able to check unique users in a license perspective)
  • Logs of the application itself. All critical data is encrypted in the logs and can only be decrypted with the customers unique encryption / decryption key.

We are able to access the following data in your O365 tenant. But this data is stored in the customers tenant only.

  • Read and write O365 groups
    • Update O365 groups from the GroupMgr
    • Sync O365 group data to the GroupMgr
    • Create new O365 groups
    • Read Team channel chat activity to get the last chat activity from a group (no chat content is queried)
  • Read and write on the Azure AD
    • Read the O365 group creation setting on tenant level
    • Update the O365 group creation setting on tenant level
  • Full control in SharePoint sites
    • Store all data for the GroupMgr in the customers tenant
  • Read Activity Feed of the Audit logs
    • Track SharePoint and Teams activity for your O365 groups.

2. Access to data

Any data stored in the GroupMgr application is protected from unauthorized access.

All critical data is securely stored in the customers tenant. The data kept on our SQL database is also protected from unauthorized access. Only a few of our own employees can access this data in case this is needed.

On rare occasions, we could ask for the logging decryption key to inspect the logs in case of any bug or to troubleshoot problems.

3. Authorization of web services

In all our web services there is a OAuth security layer. No web api could be called without a valid OAuth token from a registered and licensed customer.

We make use of the Azure AD OAuth token that can be generated from an authorized user in the O365 environment of the customer.

All the valid OAuth tokens have an expiration date, and GroupMgr will try to generate these on the fly while a user is accessing our application. If the current user is not authorized in the customers tenant, no access will be provided.

Note: auth tokens / credentials are not stored nor cached by GroupMgr.

All data should be sent over HTTPS to our web API’s, so all traffic is encrypted.

Although the exact encryption method varies browser by browser, GroupMgr requires strong TLS encryption between GroupMgr and the User for the initial authorization. All our OAuth token exchange use TLS v1.2 to connect to the authorizing server. OAuth will allow the user to deny GroupMgr access to the third-party service at any time by revoking our token.