The five ‘no’ questions an audit asks

An audit is not an exam about technology. It is five questions about control, asked slowly, by someone who has heard every reassuring answer before and trusts none of them. The questions are not clever. They are the dull ones — who can do what, where does the data go, and can you prove it. A mission-driven org with no architect on staff tends to fail them not because the answers are hard, but because nobody decided the answers in advance. The scramble starts the week the audit notice lands, and the scramble is where the real cost lives.

The good news is unglamorous: every one of these questions has a boring, durable fix you can put in place on a quiet Tuesday, months before any auditor calls. Here are the five questions, why each one bites, and the dull decision that answers it.

1. “Who can create a Power App — and who reviews them?”

This is the question that exposes shadow IT faster than any scan. Power Platform ships with a default environment that, left untouched, lets every licensed user build apps and flows that touch real data. By the time an auditor asks, the honest answer is usually “everyone, and nobody.”

Why it bites. An app a departing intern built against the HR list is now a load-bearing process nobody owns. There is no review gate, no inventory, no second pair of eyes between “I made a thing” and “the thing moves personnel data.”

The boring-first fix. Decide the maker population on purpose, then make the platform enforce it:

• Restrict the default environment. Turn off the ability for everyone to create new environments, and treat the default environment as untrusted — nothing important lives there.
• Give makers a named home. Create dedicated dev / test / production environments with explicit maker and admin roles, so building a real app means building it somewhere governed.
• Keep an inventory. The Power Platform admin center and the Center of Excellence starter kit will tell you every app, flow, and maker. “We don’t know” is the only wrong answer here, and it’s avoidable.

2. “Where does data leave the tenant?”

Auditors care less about what your data does inside Microsoft 365 than about the moment it crosses the boundary — to a personal OneDrive, a third-party connector, an unsanctioned SaaS, an inbox forward rule. Every one of those is a door, and the question is whether you know how many doors there are.

Why it bites. A single Power Automate flow with a generic HTTP or third-party connector can quietly ship records to a service nobody vetted. Multiply that by a few hundred citizen-built flows and “where does data leave?” becomes a question you genuinely cannot answer under pressure.

The boring-first fix. Draw the boundary once, in policy, and let the platform hold it:

• Write a Data Loss Prevention (DLP) policy. In the Power Platform admin center, sort connectors into business, non-business, and blocked. A connector in “business” can’t share data with one in “non-business” in the same app — that one rule kills most accidental exfiltration paths.
• Block what you can’t govern. Generic HTTP, custom connectors, and consumer services belong in the blocked tier until there is a reason and an owner for each exception.
• Constrain sharing in M365. Set sane external-sharing defaults on SharePoint and OneDrive, and disable auto-forwarding rules to external domains. The boundary you never defined is the one the auditor finds.

3. “Who has standing admin rights?”

The auditor will ask for your list of Global Administrators, and they already suspect the answer is “more than there should be, permanently.” Standing privilege is the single fattest target in any tenant: every always-on admin account is a key left in a lock, useful to an attacker every minute of every day.

Why it bites. Small orgs hand out Global Admin because it’s the path of least resistance — it makes the ticket go away today. Two years later there are nine global admins, three of whom have left, and no record of why any of them needed it.

The boring-first fix. Make privilege scarce, scoped, and temporary:

• Least privilege by role. Use Entra ID’s built-in scoped roles (User Administrator, Helpdesk Administrator, and so on) instead of Global Admin for day-to-day work. Most people doing “admin” need a narrow slice, not the master key.
• Just-in-time elevation. Where the licensing allows, put privileged roles behind Privileged Identity Management (PIM) so admin rights are activated for a window, with justification, not held permanently.
• Cap and protect the top. Keep Global Admins to a tiny, named set (the common guidance is fewer than five), every one with phishing-resistant MFA, plus one break-glass account stored offline and monitored.

4. “What happens to a leaver’s access?”

This is the question that reveals whether your governance is a living process or a one-time project. An auditor will pick a name from a recent leavers’ list and ask you to walk through exactly what happened to their account, their app ownerships, their shared files, and their licences. The pause before you answer is the finding.

Why it bites. Deprovisioning is nobody’s favourite job and rarely anyone’s named responsibility. Accounts get disabled but not reviewed; the leaver still owns three Power Apps and a critical flow; their mailbox still receives data; their licence still costs money. The access didn’t leave when the person did.

The boring-first fix. Make off-boarding a checklist a non-specialist can run, and review the rest on a schedule:

• Write the leaver runbook. Disable sign-in, revoke active sessions and tokens, reassign or quarantine owned apps and flows, convert the mailbox, reclaim the licence — in that order, every time, by whoever holds the ticket.
• Run access reviews. Entra ID access reviews let you re-attest group and role membership on a cadence, so stale access surfaces on a calendar instead of during an audit.
• Own the orphans. Apps and flows whose maker has left need a defined hand-off, not silent failure six months later when the flow stops and nobody knows why.

5. “Can you prove any of this?”

The previous four questions are about controls. This one is about evidence, and it is the question that quietly fails the most organisations. You can have good practices and still fail the audit if you cannot show, after the fact, who did what and when. An assertion is not evidence. A log is.

Why it bites. “We always review access” means nothing without the review records. “Only admins can do that” means nothing if you can’t produce the audit trail showing they were the only ones who did. Mission-driven orgs often discover at audit time that the logging was never switched on, or that retention was set to a window that already expired.

The boring-first fix. Turn on the evidence trail before you need it:

• Enable unified audit logging. In Microsoft Purview, confirm audit logging is on across the tenant and that retention matches your compliance horizon — not the default that drops events sooner than your auditor’s lookback window.
• Log the platform too. Power Platform and Dataverse activity logging, plus Entra ID sign-in and audit logs, give you the “who created, who elevated, who shared” record an auditor expects to exist.
• Make the artifacts findable. A short evidence register — where each log lives, what it proves, how to pull it — turns a week of scrambling into a half-day of exports.

When I built an internal-ops platform for a mission-driven org, the single most useful design decision was the dullest one: every meaningful action wrote an append-only audit row, keyed by actor, target, action, and time. Nobody asked for it in the demo. It is the first thing that mattered when the evidence question came.

The pattern under the five questions

Notice what none of these fixes are. None of them is a product you buy. None is a compliance dashboard, an AI copilot for governance, or a consultant’s framework with a trademark. Every one is a decision someone with authority made on purpose and wrote down: who can build, where data may go, who holds the keys, what happens at the exit, and where the proof lives. The platform already enforces all of it — the work is deciding, not buying.

That is the whole of boring-first governance. The org that scrambles through an audit and the org that exports a half-day of evidence are usually running the same Microsoft 365 tenant. The difference is that one of them answered the five questions on a quiet Tuesday, months early, and the other met them for the first time in the audit room. The calm, governed, written-down version outlasts the loud, ungoverned one every time — and the boring move that makes it true is simply deciding the answers before you’re asked.