Skip to content
English - Australia
More support
Contact us
  • There are no suggestions because the search field is empty.

Privacy Protection and Anonymisation

Privacy-by-Default Design Philosophy

SWOOP’s analytics capabilities are designed with privacy as a foundational principle. The default posture is to minimise exposure of personal data, with a strong preference for aggregated and sanitised reporting, and with identifiable data surfaced only where there is a clear and justified business purpose. The approach recognises that privacy objectives and business objectives are not always identical, and therefore provides configurable controls to balance both.

Data Collection Model: Pseudonymised, Not Fully Anonymised

At the point of data collection, SWOOP captures activity data using Microsoft 365 Object IDs rather than names, email addresses, or network IDs. These identifiers are:

    • Not directly identifiable without access to Microsoft Graph
    • Not equivalent to usernames or email addresses

Because these Object IDs can technically be resolved back to individuals by authorised Microsoft 365 administrators, the data is classified as pseudonymised, not fully anonymised. Full anonymisation (where re-identification is impossible) is not technically feasible for the use cases SWOOP supports.

Why Full Anonymisation Is Not Feasible

Full anonymisation would prevent the segmenting data by business unit, location, job role, or geography. For this reason, anonymisation at source would render the analytics ineffective for their intended business purposes.

There are also some product and feature-specific cases that would not be possible to deliver with full anonymisation. For example SWOOP for SharePoint's health scores rely on knowing if the person who created or last modified a page still has an active license for SharePoint as this identifies orphaned content.

Data Presentation: Names Are Highly Restricted

Although data is pseudonymised at collection, names are only shown in a very small number of reports, and only where there is an explicit business rationale. Examples mentioned include:

    • “Influential People” report in SWOOP for Viva Engage
    • “Influential Editors” in SWOOP for SharePoint Intranet
    • Optional personal benchmarking for selected leaders in SWOOP for Viva Engage, SWOOP for Teams and SWOOP for M365

The vast majority of dashboards do not display individual names. Those that do can be disabled.

Administrative Controls to Reduce Personal Data Exposure

SWOOP provides multiple configuration-level privacy controls, including:

a. Feature-Level Controls

Specific reports that surface identifiable data (e.g., benchmarking or influential people views) can be turned off entirely.

b. Minimum Group Size Thresholds

SWOOP supports a minimum segment size rule (e.g. 5 or 10 users). If a selected segment contains fewer than the threshold, data is suppressed and reported as “too few people to report,” reducing re-identification risk.

c. Access Controls

Access to analytics can be restricted to a small, named group of users, either managed directly in SWOOP or via Microsoft Entra ID (Azure AD) groups. This limits exposure to trained, authorised users only.

Geographic and Jurisdiction-Based Exclusions

To support global organisations with differing regulatory environments (e.g. Germany, China, France), SWOOP can:

    • Identify users by country attribute (from Entra ID or equivalent)
    • Exclude users from specific countries from processing

This approach allows organisations to proceed in most regions while addressing works council or regulatory concerns in specific jurisdictions.

Handling of Excluded Data

When users are excluded due to geography or policy:

    • Data is not deleted at source
    • It is segregated and not processed
    • This allows SWOOP and the customer to demonstrate compliance and traceability

For interaction-based platforms (e.g. Viva Engage), exclusions are applied consistently to both sides of an interaction (e.g. a “like” given and received).

Alignment with Employment and Internal Use Context

SWOOP operates strictly as a data processor, not a controller. For internal communications platforms:

    • Consent is assumed to be covered by existing employment or contractor agreements
    • No separate opt-in is required or implemented by SWOOP
    • This mirrors Microsoft 365’s own internal-use data handling model

Any additional user agreements (e.g. Viva Engage usage policies) are customer-controlled.