Back to Articles
    Technology & Security

    Permissions Hygiene Before Copilot: Cleaning Up SharePoint and Drive First

    An AI assistant inside Microsoft 365 or Google Workspace does not get its own key to the building. It borrows the key of whoever is typing. That sounds reassuring until you consider what a decade of quick shares, inherited folders, and "anyone with the link" documents has quietly accumulated inside a nonprofit's file storage. The permissions were always wrong. What changes when Copilot or Gemini switches on is that finding the wrong thing stops requiring curiosity, patience, and knowledge of where to look. It requires a sentence.

    Published: September 11, 202615 min readTechnology & Security
    Nonprofit staff reviewing file sharing permissions across SharePoint and Google Drive before deploying an AI assistant

    Microsoft 365 Copilot retrieves content using the identity of the person asking. Gemini in Google Workspace does the same thing against Drive, Gmail, and Calendar. Neither product adds a separate permission layer of its own, and neither one grants a user access to anything they could not already reach through search or a direct link. This is the single most important technical fact about deploying an AI assistant on top of your existing file storage, and it cuts both ways. It means the assistant is not a new hole in your security model. It also means the assistant will faithfully surface every hole you already have.

    For most nonprofits, those holes are substantial and largely invisible. The organization moved to Microsoft 365 or Google Workspace at some point in the last ten years, often in a hurry, often during a migration handled by a volunteer or a part-time consultant. Files came across in bulk with permissions flattened or broadly granted. A development director shared a folder with the whole staff so a colleague could grab one spreadsheet. Someone turned on link sharing for a board packet so a trustee could open it from a personal device. A grant consultant was added as a guest in 2021 and never removed. None of this felt risky, because nobody browses their coworkers' folders for fun and the search experience was mediocre enough that stumbling across the wrong file took real effort.

    An AI assistant removes that friction completely. A staff member who asks "what are the salary bands for program staff" or "summarize what we know about our largest donors" is not attempting to breach anything. They are asking a reasonable operational question, and the assistant answers it from whatever it can legitimately reach on their behalf. If the HR compensation workbook sits in a folder shared with all staff because someone needed the benefits summary out of it three years ago, that answer arrives with citations, confidently, in a few seconds. The person who asked did nothing wrong. The permissions did.

    This article covers the cleanup that should happen before the rollout rather than after the first uncomfortable discovery: how to think about the risk categories that matter most to a nonprofit, how to run a real audit in SharePoint and OneDrive and in Google Drive, a phased remediation sequence that does not require pausing the organization's work, the governance habits that keep the environment clean afterward, where AI genuinely helps with its own preparation, and what a small team with no dedicated IT staff can realistically accomplish in a few weeks.

    Amplification, Not Creation: What Actually Changes

    It helps to be precise about the mechanism, because vague warnings about AI security lead to vague responses. Copilot and Gemini both operate on the principle of user-identity retrieval. When a staff member asks a question, the assistant queries the underlying search index on that person's behalf and receives back only the items that person's account is permitted to open. No new access is granted. No permission is bypassed. The assistant is, in a narrow technical sense, no more dangerous than the search box that was already there.

    What changes is the discovery cost. Latent access, meaning access a person technically holds but has never exercised, has always existed in every file system. It stayed harmless because exercising it required knowing what to look for and where. An AI assistant converts latent access into discovered access at conversational speed, across the entire corpus, without the user needing to know a filename, a folder, or even that the document exists. It also synthesizes. A user does not receive one overshared file, they receive a summary drawing on eight of them, which means partial exposures that were individually unremarkable can combine into something that is not.

    There is a second amplification worth naming. Assistants surface content confidently and without context. A file that a human would open, glance at, recognize as a stale draft or an internal deliberation, and close again gets treated by an assistant as an equally valid source. The 2019 compensation plan that was never adopted, the board discussion document listing candidates for a leadership transition, the program memo listing clients by name that should have been deleted after the evaluation ended: none of these carry a signal the model reads as "do not repeat this." Discoverability and authority arrive together.

    This framing matters for how you talk to your board and your leadership team. The honest message is not that Copilot is unsafe. It is that Copilot is an audit of your file permissions that you did not schedule and cannot control the timing of. Organizations that have been meaning to clean up their SharePoint for five years are about to find out what is in it, in front of staff, one question at a time. That reframe usually moves the cleanup from a someday project to a prerequisite, which is exactly where it belongs. It also connects naturally to the identity and access discipline covered in our guide to zero trust security for nonprofits, where least privilege is the organizing idea rather than an afterthought.

    What an AI assistant does and does not do to your permissions

    Be accurate about the risk so the response is proportionate

    • It does not grant access to anything the user could not already open
    • It does not bypass sharing settings, site permissions, or group membership
    • It does collapse the effort required to find something from hours to seconds
    • It does combine fragments from many files into a single readable answer
    • It does treat stale, draft, and deliberative documents as authoritative sources
    • It does make the exposure visible to staff rather than theoretical to IT

    The Five File Categories That Matter Most in a Nonprofit

    A full permissions audit of a ten-year-old tenant is a large job. A targeted one is not, and targeting is what makes this achievable for an organization with no dedicated IT staff. Rather than attempting to reach a perfect state everywhere, identify the categories where exposure does actual damage and secure those first. In a nonprofit, five categories account for nearly all of the real risk.

    Donor and constituent records. Exports from the CRM, major gift prospect research, wealth screening results, giving histories, pledge schedules, and the spreadsheets that development staff build outside the database because the database is awkward. These are the files most likely to have been shared broadly for a campaign and never unshared, and they are the ones whose exposure most directly threatens the relationships the organization depends on. A prospect research memo characterizing a donor's capacity and motivations is not a document you want any staff member to be able to retrieve conversationally. Our guide to donor data privacy in an AI environment goes deeper on the obligations attached to this category.

    Human resources files. Salary and compensation workbooks, performance reviews, disciplinary records, benefits enrollment with dependent information, immigration documentation, accommodation requests, and investigation notes. HR exposure is the most common source of internal incidents in small organizations, partly because HR is often handled by an executive or operations person whose personal drive was never structured for confidentiality, and partly because payroll and benefits work generates files that get shared with a manager for one question and remain shared forever.

    Board and governance materials. Executive session minutes, leadership succession discussions, compensation committee work, conflict of interest disclosures, litigation correspondence, merger exploration, and the candid strategy memos that boards need in order to function. This category is distinctive because the harm is not primarily legal. It is that a board which discovers its deliberations are discoverable by staff stops deliberating in writing, and the organization loses its governance record. Preparation and distribution practices for these documents are covered in our piece on building board packets with AI.

    Client and program participant records. Intake forms, case notes, assessments, service plans, incident reports, and evaluation datasets that were supposed to be de-identified and often are not. For organizations subject to HIPAA, federal confidentiality rules for substance use treatment, state child welfare confidentiality statutes, or the data rules attached to a HUD or state contract, this category carries specific legal obligations and specific penalties. It is also the category where staff most often have a legitimate need for some records and no legitimate need for others, which makes flat program folders a genuine problem rather than a theoretical one.

    Grant budgets and financial detail. Proposal budgets with indirect rates and salary allocations, declined applications, funder correspondence, audit workpapers, and the internal financial models that show what programs actually cost. Nonprofits frequently underestimate this category because the numbers feel administrative rather than sensitive. In practice, a staff member who can retrieve every colleague's salary allocation across four grant budgets has effectively retrieved the salary roster, and a funder who learns what you told a different funder about the same program has a conversation with you that nobody enjoys.

    Test prompts that reveal exposure fast

    Run these yourself, from a standard staff account, before rollout

    • What are the salary ranges for staff at this organization?
    • Summarize the most recent executive session board discussion
    • Who are our largest individual donors and what do we know about them?
    • List any documents mentioning a performance improvement plan
    • What did we budget for the program director role in our federal grants?

    Where the sensitive files usually turn out to be

    The recurring hiding places in a small nonprofit tenant

    • An executive's personal OneDrive or My Drive, shared broadly years ago
    • A general Operations or Admin site that every employee was added to
    • Migration folders named Old Server, Archive, or Files To Sort
    • Teams sites created for a project and abandoned with a departed owner
    • Attachments living in shared mailboxes nobody has pruned

    Running the Audit in SharePoint, OneDrive, and Purview

    Microsoft has built a fairly complete set of tools for exactly this problem, largely because oversharing became the most common obstacle to Copilot adoption across its customer base. The tooling sits in three places, and knowing which question each one answers keeps the work from sprawling.

    Data access governance reports in the SharePoint admin center. These are the starting point and the highest-value thirty minutes in the entire process. Under Reports, the data access governance section produces lists of sites sorted by exposure type: sites shared with "Everyone except external users," sites with organization-wide sharing links, sites with "Anyone" links that work without authentication, sites with external sharing activity, and sites containing labeled content. Microsoft documents these reports in its Copilot readiness guidance for SharePoint Advanced Management. For a nonprofit with twenty or eighty sites, these reports frequently reduce a vague anxiety to a concrete list of six or seven sites that need attention, which is a very different kind of project.

    Site access reviews. Rather than an operations manager personally deciding who should still have access to the Youth Program site, site access reviews delegate that judgment to the site owner, who actually knows. The admin initiates a review from a governance report, the owner receives a task, and the owner resolves the overshared permissions in their own site. This is the feature that makes the cleanup survivable for a small team, because the bottleneck in permissions work is almost never the clicking. It is knowing whether Maria from the partner agency still needs the folder. Note the current limitation that site access reviews cover SharePoint sites and not OneDrive accounts, which matters given how much sensitive nonprofit content lives in personal drives.

    Restricted Content Discovery and Restricted SharePoint Search. These are containment controls rather than fixes, and the distinction is worth holding onto. Restricted Content Discovery marks a site so its content stays accessible to people who navigate to it directly but does not appear in organization-wide search or in Copilot responses. Restricted SharePoint Search does something broader and blunter, limiting Copilot's reach to an approved list of sites while you work through the rest. Both are useful as temporary fences around a site you have not yet cleaned, and both become dangerous if treated as the permanent answer, because the underlying permissions remain wrong and the fence can be reconfigured by a future administrator who does not know why it was there.

    Microsoft Purview and sensitivity labels. Purview's data security posture management for AI runs an assessment that identifies sensitive data reachable by unexpectedly large audiences, content with missing or inconsistent labels, and high-risk permission patterns. Sensitivity labels are the durable control underneath all of this, because a label travels with the file rather than with its current location, and a label can be configured to block Copilot processing entirely for the most sensitive categories. Labels are also the piece most often skipped by small organizations, on the reasonable grounds that classifying everything is impossible. The productive compromise is to define three or four labels rather than twelve, apply them by default at the container level for the categories that matter, and accept incomplete coverage of everything else.

    One licensing note that changes the calculus for nonprofits: SharePoint Advanced Management, which supplies the governance reports and access reviews, is included with Microsoft 365 Copilot licenses rather than sold only as a separate add-on. If your organization is licensing Copilot at all, the cleanup tooling is already paid for. Our overview of Copilot pricing and deployment for nonprofits covers how the license tiers fit together and where the nonprofit discount applies.

    Running the Audit in Google Workspace

    Google Workspace presents the same underlying problem with a different shape. There are fewer purpose-built readiness reports than Microsoft now ships, but the sharing model is simpler and the structural fix is clearer, which balances out for most small organizations.

    The My Drive problem. The single largest source of Drive exposure in nonprofits is not misconfigured sharing settings. It is that important organizational files live in individual My Drive accounts rather than in shared drives. A file in My Drive is owned by a person, inherits that person's sharing choices, and disappears into a complicated recovery process when that person leaves. A file in a shared drive is owned by the organization and governed by the drive's membership. If you do nothing else in Google Workspace before turning on Gemini, move the categories from the previous section into properly scoped shared drives. It resolves ownership, sharing, offboarding, and discoverability in one action.

    Link sharing defaults. In the Admin console, under Apps, Google Workspace, Drive and Docs, the sharing settings control whether files can be shared outside the domain, whether link sharing defaults to restricted or to anyone in the organization, whether warnings appear for external shares, and whether users can publish to the web. Many nonprofit tenants were configured years ago with permissive defaults and have never been revisited. Changing the default to restricted does not retroactively fix existing files, but it stops the problem from growing while you work on the backlog, which makes it the correct first move rather than the last.

    Drive audit logs and the security investigation tool. The Drive log events in the Admin console record sharing changes, link visibility changes, external shares, downloads, and access grants, and they are queryable and exportable. On Workspace editions that include the security investigation tool, you can search for patterns rather than individual events: all files shared publicly, all files shared with a specific external domain, all sharing changes made by a departed employee in their final month. Google has also added audit logging that records when Gemini accessed a Drive file to answer a user query, which gives you an after-the-fact view of what the assistant is actually reaching for. That log is worth checking in the first weeks of a rollout, because it turns assumptions about exposure into observations.

    Groups as the access layer. Google Groups membership drives access to shared drives and to files shared with a group, which means group hygiene is permission hygiene. Groups that accumulated members over years, groups whose purpose has changed, and groups containing external addresses that nobody has reviewed are all direct paths to overshared content. Auditing a dozen groups is faster than auditing ten thousand files and generally fixes more.

    Organizations weighing which platform to standardize on, or running both after a merger, will find the practical comparison in our piece on Google Workspace and Microsoft Copilot for nonprofits useful for understanding where the governance tooling differs.

    Audit checklist by platform

    The specific places to look before an assistant goes live

    • Microsoft: data access governance reports for broad-audience and Anyone links
    • Microsoft: sites with no owner, or an owner who has left the organization
    • Microsoft: guest accounts in Entra ID with no sign-in activity in twelve months
    • Google: organizational files sitting in individual My Drive rather than shared drives
    • Google: domain sharing defaults and whether anyone-with-link is still permitted
    • Google: group membership, especially groups containing external addresses
    • Both: shared mailboxes, calendars, and any legacy file server sync still running

    A Remediation Sequence That Does Not Stop the Organization

    The instinct after a first look at the audit reports is to lock everything down. Resist it. Aggressive blanket restriction in a small nonprofit reliably produces three days of people unable to open files they need, a flood of requests to the one person who understands the admin console, and a quiet decision by staff to start emailing attachments to each other again, which is worse than where you started. Sequencing matters more than speed.

    Phase one: stop the bleeding. Change the defaults so new oversharing stops happening while you address the backlog. Set default link types to specific people rather than anyone in the organization. Disable anonymous "Anyone" links entirely, or restrict them to a short expiration if a program genuinely needs them for external submissions. Require sign-in for external sharing. Turn on expiration for guest access. None of this touches existing files, so nothing breaks, and it converts the problem from growing to finite. This phase takes an afternoon.

    Phase two: fence the worst sites temporarily. Take the handful of sites your reports flagged as most exposed and containing the most sensitive material, and apply a containment control while you work on them. In Microsoft, that is Restricted Content Discovery or Restricted Access Control on those specific sites. In Google, it is tightening the shared drive membership and sharing settings. The goal here is buying time, not finishing. It means that if leadership decides to switch the assistant on next week, the two or three genuinely dangerous locations are already out of scope.

    Phase three: fix the five categories properly. Now do the real work, one category at a time, starting with HR because it is usually smallest and highest-consequence, then board materials, then client records, then donor data, then grant financials. For each, establish the correct home, meaning a site or shared drive with an explicit membership list, move the content there, remove the old broad grants, and confirm that the people who need access have it. Handle each category as a discrete project with an owner and an end, rather than as part of an amorphous cleanup that never finishes.

    Phase four: deal with inheritance and the long tail. Broken permission inheritance is where SharePoint environments become unreadable: a folder four levels down with unique permissions granted to a person who left in 2022, inside a library whose parent site has entirely different membership. These are tedious to find and individually low risk, which is exactly why they should come after the categories that matter. The same is true of the migration folders full of unsorted files. A defensible approach for the long tail is to archive rather than sort, moving genuinely old material into a restricted archive location that is excluded from assistant indexing, and dealing with it only if someone asks.

    Phase five: pilot narrowly, then widen. Turn the assistant on for a small group, ideally including at least one person from finance or HR who will recognize a file that should not have surfaced. Ask them to actively probe, not just to use it for drafting. Give them a simple channel to report anything that looks wrong and a promise that reporting it creates no trouble for anyone. Two weeks of genuine probing by five people finds more than a month of administrative review, and the findings arrive with the context that makes them fixable. This is also the moment to connect the rollout to your written expectations, which is where an acceptable use policy for AI tools earns its place.

    Sequencing at a glance

    Each phase leaves the organization working

    • Tighten defaults so the backlog stops growing, without touching existing files
    • Fence the two or three most exposed sensitive locations as a temporary measure
    • Rehome HR, board, client, donor, and grant financial content on purpose
    • Repair broken inheritance and archive the migration debris rather than sorting it
    • Pilot with people who will probe, and make reporting a surprise consequence-free

    Governance That Keeps the Environment Clean

    Every organization that has done this cleanup once knows the real risk is doing it again in three years. Permissions decay continuously because the forces that create oversharing are ordinary and constant: people need to collaborate, sharing broadly is faster than sharing precisely, and nothing ever prompts anyone to remove access. Governance is the small set of recurring habits that counteract that drift without requiring anyone to care about permissions on a daily basis.

    Shared team storage, not personal storage, by default. This is the highest-leverage structural rule available. Organizational work lives in shared drives or SharePoint team sites owned by a team, not in an individual's OneDrive or My Drive. Personal storage is for drafts and genuinely individual material. The rule is easy to state, and the way to make it stick is to make the shared location obviously better: clear names, sensible structure, and a real answer to "where does this go." Content in a shared container inherits governance automatically, survives departures, and never generates the awkward conversation about accessing a former employee's files.

    Naming conventions that encode sensitivity. A site or drive called "HR Confidential" behaves differently from one called "Operations" not because of the label but because the name tells every future person adding a member what they are doing. Conventions that distinguish internal from external-facing, and restricted from general, prevent a large share of accidental sharing at the point of decision. This connects directly to how discoverable your institutional knowledge is, which our guide to knowledge management for nonprofits treats as a design problem rather than a storage problem.

    Access reviews on the calendar, owned by someone. Quarterly is realistic for a small organization, and quarterly means a recurring calendar entry with a named owner, not an intention. The review does not need to be exhaustive. Confirm every site and shared drive has a current, employed owner. Review guest accounts and remove anyone inactive. Look at the governance reports for new broad-audience shares since last time. Check that anyone who changed roles has had their access changed to match. Ninety minutes a quarter, done reliably, keeps an environment in better shape than an annual project that gets postponed.

    Offboarding that includes access, not just accounts. The most common gap in nonprofit offboarding is that the account gets disabled and everything else persists. The departed employee's sharing links keep working for their recipients, their group memberships stay in place, their OneDrive content remains unreachable to the team that needs it, and the sites they owned become orphaned. A written offboarding checklist should cover transferring ownership of files and sites, removing group memberships, revoking sharing links the person created, reassigning any shared drive ownership, and documenting what was moved. The same discipline applied to arrivals in our piece on automating staff onboarding works in reverse, and departures are the higher-risk direction.

    A written policy that says where things live. None of the above survives turnover unless it is written down. A short document naming the storage locations, the categories that must live in restricted locations, the sharing rules, the review cadence, and the owner of each is enough. It does not need to be long. It needs to exist and be findable, and it should be reviewed with the same rhythm as the rest of your data governance policy.

    Quarterly access review, ninety minutes

    Short enough to actually happen

    • Every site and shared drive has a current owner who still works here
    • Guests inactive for twelve months are removed, not reviewed again
    • New broad-audience or anonymous links since last quarter are examined
    • Role changes in the last quarter have matching access changes
    • The five sensitive categories are still where the policy says they are

    Offboarding steps people forget

    Disabling the account is the beginning, not the end

    • Transfer ownership of personal drive content the team still needs
    • Reassign ownership of any site or shared drive they owned alone
    • Revoke sharing links they created, which outlive the account
    • Remove them from groups, distribution lists, and external collaborations
    • Record what was moved and where, so the next person can find it

    Using AI to Prepare for AI, and Where That Stops

    There is a pleasing symmetry in using a language model to help clean up the environment before deploying a language model into it, and the help is real, provided you are clear about which parts of the work are language problems and which are access problems. The distinction is simple: anything involving reasoning over text you have already exported is a good use. Anything involving reaching into live systems and changing permissions is not.

    Making audit exports readable. A data access governance export or a Drive log query returns a CSV that is technically complete and practically unusable, with thousands of rows and columns whose meaning is not obvious. Pasting that export into an assistant and asking which sites appear most often, which sharing types dominate, which items involve external domains, and what a reasonable priority order would be turns an hour of squinting into a few minutes. The output is a starting list for you to verify, not a set of conclusions to act on blindly, and the underlying data is one you already hold.

    Classifying a file inventory by likely sensitivity. Export a list of file and folder names, without contents, and ask a model to flag which ones probably contain HR material, donor records, client information, board material, or financial detail based on naming patterns. It will be imperfect, and it will miss the file called "Book1.xlsx" that holds the entire salary schedule. What it does well is reduce forty thousand names to a few hundred worth a human look, which is the difference between a feasible review and an impossible one. Treat the output as a triage queue.

    Drafting the policies and the communications. The storage policy, the offboarding checklist, the naming convention document, the staff email explaining why folders are moving, and the board memo describing the risk and the plan are all short documents that go unwritten because they are tedious rather than difficult. Describing your situation and having a model produce structured first drafts removes the blank page. The revision loop is where it earns its keep, particularly in translating the same content for three audiences: the staff who need to know what changes on Monday, the board that needs assurance, and the auditor who wants the control described.

    Generating the questions you are about to be asked. Hand a model your remediation plan and ask it to respond as a skeptical board treasurer, then as a program director worried about losing access to files, then as an auditor reviewing your controls. The questions it produces are not exotic, which is the point. They are the obvious ones, and the obvious ones are the ones you will actually face. Preparing answers before the meeting is the cheapest hardening available.

    Where this stops. AI does not decide who should have access to what. That is an organizational judgment about roles, trust, and legal obligation, and it belongs to the people accountable for the consequences. It cannot see your live permission structure unless you give it an export, and giving it an export means thinking about what that export contains before you paste it anywhere. Do not upload audit data containing client names, donor identities, or employee information into a consumer tool without checking the vendor's data handling terms first, and prefer a tool operating under your organization's own tenant agreement where one is available. Regulatory specifics it offers about HIPAA, state privacy law, or a funder's data requirements should be verified against the actual source, since confidently wrong citation is the characteristic failure of these tools. And the person who signs off that the environment is ready for an assistant is a person. That does not move.

    Reasonable to delegate

    Language work on data you already exported

    • Summarizing and prioritizing governance report exports
    • Triaging a file and folder name inventory by likely sensitivity
    • Drafting storage policies, checklists, and staff communications
    • Producing the board and auditor versions of the same plan
    • Anticipating objections and questions before the meeting

    Keep with a named human

    Judgment, access, and accountability

    • Deciding which roles should have access to which categories
    • Making any actual permission change in a live system
    • Interpreting a funder contract or a confidentiality statute
    • Deciding what data is safe to paste into an external tool
    • Signing off that the environment is ready for a wider rollout

    What a Small Team Can Realistically Do in Six Weeks

    Vendor guidance on this topic tends to assume an enterprise with a dedicated identity team, which is not the situation of a nonprofit where the person with global admin rights is the operations director and permissions work competes with payroll, the audit, and a grant report due Friday. The good news is that the categories that matter are small, the highest-value work is front-loaded, and the tools do more than they did two years ago. A meaningful cleanup is a matter of weeks of part-time attention, not a consulting engagement.

    Week one, roughly four hours. Run the governance reports or the Drive sharing queries and read them. Run the test prompts from a standard staff account if you already have an assistant license, or use the existing search experience as a proxy if you do not. Write down what you found in a single page. This week is diagnosis, and its main output is that the conversation stops being speculative.

    Week two, roughly three hours. Change the defaults. Sharing link defaults, anonymous link policy, external sharing requirements, guest expiration. Apply temporary containment to the two or three worst locations. Brief leadership with the one-page finding and the plan. Nothing visible changes for staff this week, which is intentional.

    Weeks three and four, roughly six to eight hours. Rehome the sensitive categories. HR first because it is small and consequential, then board materials, then whichever of client records, donor data, and grant financials is most exposed in your environment. Expect this to be the part that generates conversations, because moving a folder that four people use requires telling those four people. Budget more time for the communication than for the clicking.

    Week five, roughly three hours. Guests and orphans. Remove inactive guest accounts, assign owners to sites that have none, and work through departures from the last two years that were never properly offboarded. This is unglamorous and tends to remove more latent access per hour than anything else on the list.

    Week six, roughly four hours. Write the short policy, set the quarterly review on the calendar with a named owner, add the access steps to the offboarding checklist, and start the pilot with a handful of people who will genuinely probe. Then widen deliberately rather than all at once, and expect the pilot group to find two or three things the reports did not.

    What this schedule deliberately does not attempt is a perfect environment. The migration folder with eleven thousand unsorted files will still be there. Broken inheritance four levels deep in the program library will still be there. Those are worth addressing eventually, and they are not worth delaying a rollout that staff are asking for. The categories that would cause real harm are handled, the defaults no longer manufacture new problems, and there is a recurring review that will catch the rest over time. That is a defensible position, and it is achievable by an organization with no IT department at all. Organizations pairing this work with a broader readiness effort will find the sequencing in our nonprofit AI readiness checklist a useful companion.

    Conclusion

    The permissions problem waiting inside most nonprofit file storage was not created by AI and will not be solved by declining to use it. It was created by a decade of reasonable people making small, fast sharing decisions with no mechanism to reverse them, and it has been sitting there generating no consequences because nobody had a good reason to look. An AI assistant is simply the thing that gives everybody a reason to look, all at once, without meaning to.

    That makes the cleanup a genuine prerequisite rather than a nice-to-have, but it also makes it tractable, because the assistant tells you what matters. You do not need a perfect environment. You need the five categories that would cause real harm to be in properly scoped locations, defaults that stop manufacturing new exposure, the worst legacy sites fenced or fixed, and a quarterly rhythm that catches the drift. Everything else can wait, and pretending otherwise is how these projects stall before they start.

    There is also a benefit worth naming, because it is easy to frame this entirely as risk. Organizations that do this work end up with something they did not have before: a file environment where people can find things, where ownership is clear, where a departure does not strand institutional knowledge, and where new staff can be told plainly where things live. The AI assistant works dramatically better on a clean environment too, because retrieval quality tracks organization. The cleanup is presented as a security project, and it is one. It is also the storage reorganization the organization has needed for years, finally given a deadline.

    Clean Up Before You Switch It On

    We help nonprofits audit SharePoint and Google Drive permissions, fix the exposure that matters, and put governance in place before an AI assistant goes live.