Implementing Indigenous Data Sovereignty Principles in SharePoint

Turning principles into practice can seem challenging, but SharePoint has flexible features that you can configure to support Indigenous Data Sovereignty. Let’s break down how you can adapt SharePoint’s information architecture, settings, and processes to uphold IDS:

The foundation of IDS is partnership. Before diving into technical settings, establish a partnership with the Indigenous people whose data is in your system:

• Consult Early: Involve Indigenous representatives when setting up or revamping your SharePoint site structure for a project or program. For example, if creating a SharePoint site for a community health initiative, invite members of that community or an Aboriginal-controlled health organisation to advise on data categories, sensitivity levels, and user permissions. They may suggest culturally relevant ways to group information or flag certain content as sensitive.
• Indigenous Data Governance Group: Consider forming a small Indigenous Data Governance committee or working group for your agency. This group can provide ongoing guidance on data matters. They might review SharePoint usage policies, vet requests to access sensitive data, or help decide what data can be openly shared. The Australian Public Service’s Framework for Indigenous Data Governance recommends having an Indigenous Data Champion at a senior level to drive these efforts
• Co-Design Workflows: Work together to design how data flows in and out of SharePoint. For example, co-create protocols for how files are uploaded after community consultations: Who in the community gets to review meeting notes saved to SharePoint? Will transcripts be validated by participants before wider access? By co-designing these workflows, you ensure cultural protocols are respected at each step (e.g., not naming a recently deceased person in a publicly visible list).

Tip: Partnership isn’t a one-time box tick. Maintain communication channels – maybe a quarterly meeting to discuss data management issues or new datasets. This continuous engagement means SharePoint configurations can evolve with community needs. It also gives communities confidence that SharePoint is being managed “with them, not on them.”

Metadata is the backbone of any records' system, and it’s especially key for Indigenous data. Proper metadata helps ensure context (so data isn’t decontextualised) and supports the discoverability and controlled access of records.

• Identify Indigenous Content: Introduce a metadata field or tagging system to mark records related to Indigenous peoples. For instance, you could add a column “Indigenous Content” (Yes/No) or “Community” on relevant SharePoint libraries and lists. Whenever a document or list item pertains to Aboriginal or Torres Strait Islander peoples, set the flag or specify the community name (e.g., Yawuru, Noongar, Wiradjuri, etc.). This simple step lays the groundwork for many other actions – like targeted permissions, retention rules, and easy retrieval for community requests.
• Nation / Language Group Metadata: Where applicable, include fields for Nation, Language Group, or Clan. Many standard government databases only have “Indigenous = Y/N” which erases diversity. If your SharePoint is used for data like program enrolment or research participants, capturing the specific Nation or community can be empowering. It allows grouping data in ways meaningful to those communities and may encourage community-specific insights (instead of treating all First Nations peoples as a monolith). Ensure this metadata is self-identified – let people or communities provide the terms they prefer.
• Cultural Sensitivity Labels: Not all Indigenous-related data are equal – some may be open, others extremely restricted. Work with communities to categorise sensitivity levels and reflect that in SharePoint. For example, you might use a choice column or a SharePoint Term Set for “Cultural Sensitivity” with values like: Public, Internal Use, Restricted (Elders only), Secret/Sacred (restricted). A document containing general community news might be “Internal Use” (only visible to agency and community reps), whereas a document with secret ceremony details would be “Secret/Sacred” (very tightly controlled). These labels act as signals to anyone handling the records and can tie into permission setups (discussed next).
• Descriptive Metadata Including Indigenous Knowledge: Ensure metadata descriptions respect Indigenous knowledge systems. For instance, if uploading photographs to a SharePoint library for a cultural heritage project, include descriptions that note traditional place names, names of people (with permission), or Indigenous terms (with agreed spellings) in the metadata. This creates a richer record that communities can connect with. It also implements the principle that data should be “contextual and disaggregated” – rich in detail and context, not aggregated to meaningless levels】

By tailoring metadata in these ways, SharePoint becomes a database that “sees” Indigenous peoples properly, rather than rendering them invisible or “other.” It sets the stage for applying proper access controls and for making the data truly findable by – and accountable to – the communities concerned.

One of SharePoint’s strengths is its flexible permission structure. To respect Indigenous Data Sovereignty, you’ll want to leverage that to allow Indigenous ownership and control over who sees data:

• Dedicated Sites or Libraries for Shared Governance: Consider creating separate SharePoint sites or libraries specifically for Indigenous-partnered projects, and give Indigenous partners equal admin rights over those areas. For example, if a government department and a First Nations community are co-managing a national park, set up a SharePoint site for park data and make sure community representatives are site owners along with agency staff. This technical step is powerful – it means Indigenous partners can add/remove users, structure folders, and manage content directly, exercising control over their data domain.
• Limit Access to Sensitive Content: As identified through cultural sensitivity labels or flags, apply unique permissions to highly sensitive documents. SharePoint allows item-level permissions if needed, though managing at library or folder level is easier at scale. For instance, minutes of a meeting among Elders might be stored in a folder only accessible to those Elders and a few select officials. If that information isn’t meant for general circulation (maybe it contains ceremonial knowledge), don’t put it on a broadly accessible site. Essentially, practice the “need-to-know” principle guided by Indigenous norms: if the community says only certain people should access certain data, configure SharePoint to enforce that.
• External Sharing with Communities: Often, government data about Indigenous people never makes it back to them. SharePoint can invert that. Use SharePoint’s external sharing feature to provide Indigenous community organisations or representatives access to data about them. This could be done through guest accounts or by creating a SharePoint site on your tenant specifically for data sharing with that community (with the community having accounts to log in). Example: A health department might share a dashboard or document library of local health statistics with the Aboriginal Medical Service in that region, updated in near real-time. By giving communities direct access rather than making them file formal requests, you honour the principle that Indigenous people should be able to access data about themselves easily
• Consent and Role-Based Access: Where possible, implement processes for obtaining consent for data use and reflecting that in SharePoint permissions. If you collect data from Indigenous individuals or communities, consider storing the consent forms or statements alongside the data and honouring any conditions. For personal information, SharePoint’s sensitivity labels can mark files as containing personal Indigenous info, reminding staff that the Privacy Act and cultural consent norms apply. If a community stipulates that a dataset can be used for X project but not Y, note that in the SharePoint library description or a metadata field “Usage Conditions”, and configure access so only the X project team can get to it.
• Audit and Visibility: Enable audit logging on SharePoint to track who accesses Indigenous-related records. This creates accountability – you can provide an audit trail to communities if needed, showing exactly who has viewed or downloaded their data and when. Knowing that an audit log exists can also deter inappropriate access internally.

Remember that, fundamentally, permission design should mirror Indigenous governance decisions. It might feel unusual to give non-employees (community members) higher access in your system or to segregate certain info by cultural criteria, but this is what respecting IDS can look like in practice. It ensures the “Authority to Control” rests with the people whom the data is about.

Records management is another area to align with Indigenous Data Sovereignty. Typically, government data is subject to retention schedules: after X years, records are destroyed or archived. But if those records involve Indigenous knowledge or history, hard-and-fast rules should be reconsidered with Indigenous input:

• Never Destroy without Consultation: Build in a step to consult the relevant Indigenous community before deleting any records containing their information or cultural knowledge. In SharePoint/Office 365, instead of auto-deleting records when a retention period ends, set the retention label to require a disposition review. When, say, “Project ABC Files – 7 years retention” hits that mark, a Records Manager (or better, a joint team including Indigenous reps) can review what’s in there. If some records have continuing value to the community, extend their retention or reclassify them as permanent. This prevents the inadvertent destruction of data that communities might consider part of their heritage. For example, audio recordings of Elders might technically be “research data” scheduled for deletion, but to the community that’s an irreplaceable cultural resource – so you’d opt to archive it indefinitely (with permission).
• Community Archives & Handover: When records are about a specific community, consider offering copies to that community’s own archives or knowledge centre before deletion (or as part of archiving). SharePoint’s export functions (or a simple download of files) can facilitate transferring data. For instance, after a program concludes, you might present the community with a SharePoint archive (on a USB or shared drive) of all key documents, so they hold that history as well. This acknowledges their ownership. If your agency must delete due to policy, at least you’ve ensured the community has the data they might want to keep.
• Flexible Retention Schedules: Work with archival authorities to allow flexibility in retention rules for Indigenous content. If regulations permit, label certain records as “Keep until further notice – subject to Indigenous review.” Many jurisdictions, including WA as referenced, are revisiting laws to empower sharing data with Indigenous organisations
• Protecting Collective Privacy: Indigenous Data Sovereignty also raises the notion of collective privacy – not just individual privacy. Certain data might be sensitive at a family or clan level. Configure retention and deletion in a way that respects that. For example, data about a small community’s socio-economic status might be considered “restricted until community approves release,” even if de-identified, because that community collectively might feel stigmatised by its release. In practice, this might mean retaining such data internally and not open-publishing it until you have community consent, regardless of open data urges. SharePoint can act as the secure vault where data is retained and not disposed or published prematurely.

The big takeaway is to treat Indigenous-related records with extra care at the end of their life cycle. It’s better to err on the side of preserving and consulting than to follow a rigid rule that could result in loss of knowledge or disrespect of ownership.

Technology alone won’t ensure Indigenous Data Sovereignty is upheld – people play a huge role. Invest in building understanding among those who use and manage SharePoint:

• Cultural Awareness Training: Ensure that IT staff and records managers understand why Indigenous Data Sovereignty is important. This could involve formal training sessions led by Indigenous facilitators, covering topics like historical data misuses, cultural protocols (e.g., restrictions around names/images of deceased persons), and local community preferences. When your team grasps the “why,” they’ll implement the “how” more diligently. Link the training to how they use SharePoint: e.g., explain why a certain library has restricted permissions by telling the story of that data and its cultural sensitivity.
• Practical How-To Guides: Create internal guidelines or checklists for SharePoint that incorporate IDS. For instance, a “Guide to Managing Indigenous Content in SharePoint” that lists steps like: tag the content, check permissions, consult the Indigenous Data Champion before archiving, etc. Make this guide part of your records' management manual. When adding new content, users can refer to it to make sure they’ve done things like add the right metadata and stored it in the correct secured library.
• Appoint Data Stewards: Identify and train Indigenous Data Stewards or Champions within your agency (or hire/contract Indigenous professionals into such roles). These stewards can work alongside records managers to oversee Indigenous-related datasets in SharePoint. They would be the go-to for questions like “Can we share dataset X with researcher Y?” or “Who in the community should approve releasing this document publicly?”. Having an identified person or team for this adds accountability. It also shows communities that there is someone inside the system specifically looking out for their data interests.
• User Access Training: If you are extending SharePoint access to community members (as discussed earlier), provide training and support for those users too. Not all community orgs may be familiar with SharePoint. A short onboarding on how to navigate the site, download reports, or upload their own content (if they have contributor rights) can empower them to actually use the access you’ve given. This training should be delivered in a culturally appropriate way (using clear language, perhaps delivered in-person or via screen-share rather than just sending a manual).
• Ongoing Evaluation: Incorporate checks for Indigenous Data Sovereignty into your routine audits or reviews of the SharePoint system. For example, when auditing user access, ask: Are any permissions out of line with what was agreed with the community? When reviewing content quality, ask: Is metadata being filled in, especially Indigenous tags? Use these evaluations to pinpoint needs for retraining or adjustments. You might discover, for instance, that staff in one branch keep forgetting to mark files as sensitive when they should – a reminder and tweak to the process can fix that.

Essentially, build a culture where respecting IDS is “business as usual” for your team. Just as cybersecurity or privacy training is mandatory, make understanding IDS principles a normal part of managing information. This human element will ensure that all the great configurations you put in place in SharePoint are actually used properly and consistently.

Bringing it all together, here are some best practices and action steps for IT professionals and records managers to embed Indigenous Data Sovereignty into SharePoint:

Engage with Indigenous communities before implementing tech changes. Co-design data categories, permissions, and workflows. Regular partnership meetings are key.

Create fields for “Community”, “Indigenous Content”, etc. Consistently tag records. This metadata drives everything from access control to tailored retention.

Lock down sensitive content to only those who should see it (as defined by the community). Conversely, open up access to Indigenous partners by giving them direct roles in SharePoint.

Use dedicated SharePoint sites/libraries for projects with Indigenous stakeholders, and make them co-owners. This technically enforces shared control of that data space.

Don’t auto-delete Indigenous-related records. Implement review steps and get community consent for disposal or archiving. When in doubt, keep it (or hand it over to the community) rather than destroy.

Maintain an inventory (data catalogue) of Indigenous datasets in SharePoint and share that list with the communities. They should know what information exists about them.

Educate staff on IDS principles and how to implement them in daily SharePoint use. Likewise, train Indigenous community members who interact with the system, so they can leverage it fully.

Configure SharePoint search keywords and synonyms to include Indigenous terms (place names, etc.). Ensure that if a community user searches their language or slang, the system recognizes it.

By following these practices, SharePoint can evolve from a generic document repository into a platform for digital self-determination. You’ll be enabling Indigenous data users to find and use information easily (e.g., a native title group can search their country’s name and get all relevant files because you tagged them), and ensuring that any use of the data has the necessary approvals.

Challenges? Yes, there are a few. You might encounter legacy systems that don’t play nicely with these ideals, or pushback from staff who find the extra steps inconvenient. There’s also the challenge of capacity – not all communities have resources to engage deeply on data governance. The solution is to start small and simple: apply one or two changes (like a tagging system and a consultative deletion process) and build from there. Celebrate early wins, like an instance where sharing data back led to a community insight or where collaborative governance saved a culturally important record from being lost. These stories help solidify support for IDS-aligned practices.

Indigenous Data Sovereignty isn’t anti-data or about restricting information – it’s about rightful ownership, balanced access, and mutual benefit. By configuring SharePoint with Indigenous Data Sovereignty in mind, IT professionals and records managers can turn these principles into everyday practice. Government agencies will still get the data they need, but in a way that is transparent and accountable to Indigenous peoples.

Think of it like "designing our data house with an open door and a welcome mat" for First Nations partners, rather than a one-way mirror. In practical terms, that might mean a SharePoint site where Aboriginal rangers co-manage environmental data, or a library of historical photos where traditional owners control the sharing settings. It means treating data not just as bits in SharePoint, but as stories and knowledge that communities entrust to us.

For IT teams, aligning SharePoint to IDS principles is an opportunity to innovate – to use metadata, permissions, and governance workflows in creative ways that advance social equity. For records managers, it’s about extending the concept of “record integrity” to include cultural integrity. And for Indigenous communities, these changes affirm that their voices matter in the digital space as much as on the land.

By following the strategies outlined – partnering up, tweaking metadata, locking down here, sharing there, training all around – you’ll make significant strides in respecting Indigenous Data Sovereignty. The result is a SharePoint environment that is not only compliant with laws and policies, but is also culturally responsive and just.

In the end, when we uphold Indigenous Data Sovereignty, we improve data for everyone. We create systems that are more inclusive, accurate, and robust. We build trust with communities, which opens doors to better collaboration and richer data down the line. It’s a virtuous cycle well worth starting. So let’s get to it – turn those principles into practice, one SharePoint site at a time.