Anonymised ITFR client case study. The provider name, locations and identifying details have been changed for confidentiality.
A registered NDIS provider engaged ITFR after growth across several locations made information handling increasingly inconsistent. Staff needed participant information in homes and community settings, but files were spread across email, shared drives and individual folders. Leadership wanted clearer privacy controls without making frontline work slower.
The real risk was inconsistent handling
Different teams stored similar records in different places. Access was often granted person by person, which made review and offboarding difficult. Staff sometimes emailed documents to themselves because the approved location was hard to reach from a mobile device.
We mapped information by purpose, sensitivity, owner, required access and retention. That identified where the process itself encouraged risky workarounds.
Why privacy and NDIS requirements shaped the design
The control model considered Australian Privacy Principle 11, which requires reasonable technical and organisational steps to protect personal information. It also considered the NDIS Practice Standards’ information-management outcome, including confidentiality, accurate records and proportionate systems.
CIS Controls and Microsoft security best practice helped translate those obligations into practical identity, device, data and recovery controls. We did not treat a cloud migration as compliance by itself. Policies, consent, access decisions, staff behaviour, incident handling and secure disposal remained part of the design.
How the ITFR information-protection stack was implemented
Microsoft 365 workspaces were arranged around service functions and participant teams. We used Microsoft Purview sensitivity labels with a small set of terms staff could recognise. Microsoft recommends testing label names and guidance with the people who apply them, so the pilot used real examples before wider publication. See Microsoft’s sensitivity-label deployment guidance.
Entra ID groups provided role-based access, Conditional Access protected sign-in and Intune managed supported mobile devices with encryption, screen-lock rules and remote wipe. Microsoft 365 audit information, endpoint protection and ITFR monitoring gave the support team visibility when access or devices behaved unexpectedly.
Implementation methodology
- Classify participant, workforce, finance and operational information by sensitivity, owner, access need and retention requirement.
- Create a small Purview label framework and publish it first to a pilot group using examples drawn from real care-team documents.
- Apply appropriate protection to key SharePoint locations and configure baseline DLP rules for high-risk external sharing and sensitive information.
- Replace person-by-person permissions with Entra ID role groups and review access with service managers before migration.
- Enrol supported mobile devices in Intune and validate encryption, screen lock, remote wipe and Conditional Access before field rollout.
- Test common mobile tasks with pilot users, review audit events and support tickets, then tune prompts before wider enablement.
High-risk records were separated, while routine collaboration remained quick. Staff saw short prompts and examples rather than a long policy at every action.
What improved
Access could be granted through a role and removed quickly during offboarding. Managers gained a reviewable record of external sharing. Staff stopped using personal storage for convenience because the approved workspace worked properly on mobile devices.
The provider was better prepared to demonstrate how participant information was stored, who could access it and how an incident would be handled. The biggest benefit was confidence: care teams could focus on participants without guessing whether the technology was protecting them.
