Exceptions that became the design

An exception is a grant with a story about why the ordinary rule does not apply. The story starts as a ticket. The ticket says temporary, says a name, says a reason that was true on the day. Then the date passes, or there never was a date, and the exclusion remains in the policy, the group remains in the activation bypass, the vendor account remains enabled. The review can see it now. This chapter's problem is permission to keep looking and still not act, because the exception is documented, and documented has been allowed to mean controlled.

A rule with a hole is two designs

Conditional Access is the cleanest place to see it, because the policy looks like a rule and the exclusion looks like a footnote. The rule says this population must meet this control. The exclusion says these accounts need not. On the morning of an incident the footnote is the path, and it was the path on every quieter morning too. An exclusion answers in the negative whenever the excluded account can sign in on a normal Tuesday. The exception is not a safety margin around the rule. It is a second rule, aimed at the identities you were most unwilling to constrain. Those identities are often the wide ones. You exclude them because the control might lock you out, which is another way of saying the verb they hold is too important to interrupt.

Read exclusions as objects. Deleting the exclusion would change whether a control applies. If it would change nothing, because another object still grants the verb without that policy, the exclusion is not the winning description. Say so. Sometimes the account is privileged in a directory the policy does not cover at all. The exclusion is then a comment on a path the account does not use, and the real grant is elsewhere. An exclusion earns a row when it is the reason a control you are relying on does not bind. It earns a note when it is decorative. Decorative exceptions are still worth deleting, later, as hygiene. Do not let a long exclusion list, full of harmless leftovers, hide the three exclusions that name administrative accounts.

PIM has the same shape on a different screen. A role requires approval, except for a group. A role requires a short window, except for operators who can extend their own. The except-for is the design of privileged access for the people who actually use it. Everyone else lives in the rule you show the auditor. An exception group that skips approval is standing access with a distribution list. Write the members, and if the group is nested or synced, walk the chain before you trust the short cloud list. A list of four can be forty, including leavers the on-premises group still holds. Exceptions are not exempt from staleness. They are where staleness is defended, because taking a leaver out of an emergency group feels like weakening the emergency.

Vendor and partner access is the exception that arrives with a contract. The contract said a named engineer, for an implementation window, under supervision. The account is a shared mailbox identity, or a local admin the vendor required, and the window was the go-live. Go-live was a year ago. The account is standing. Nobody wants to remove it because the vendor still "might need to get in", which is a request that has not been made and a grant that has not ended. Ephemeral vendor accounts exist so this sentence can be false. You may not have built them. Until you have built that shape, the vendor account is the design for that third party, whatever the contract called an exception. Often the grown-up left with the project.

Migration exceptions are the organisation talking in its sleep. A group called Migration-Admins, a firewall rule, a tenant trust, a temporary Global Administrator for the cutover weekend. The cutover succeeded or it did not. The group remains because removing it is a change, and the change might reveal that something still depends on it. Dependence is information. It is not a reason to leave the verb undescribed. If something still depends on Migration-Admins, the something is standing access by another name, and the name is lying. Rename nothing until you have the verbs. Renaming makes the design look intentional. It may be intentional. Hide the intention inside the word temporary and you do not have a decision.

Documented is not the same as bounded

Risk acceptance is the grown-up form of the exception, and it is where serious programmes go to stop feeling guilty. A record says the control gap is accepted, by a named person, for a named system, with a rationale. Good. Now read it against the table. Does the acceptance name the verb, or the system? A system-level acceptance ("legacy billing is accepted") covers every verb on that system, including ones nobody listed when the acceptance was signed. Does it name the objects? An acceptance that does not point at an exclusion, a group, or a local account cannot be tested. Does it have an end, and did anyone open it when the end arrived? An acceptance with a review date that passed is a ticket with a calendar failure. The failure is ordinary. The grant is not made ordinary by the existence of the record.

The owner of the fourth statement should treat an acceptance as one of the stories, not as a veto over the winning description. The acceptance says the organisation will live with the verb. The winning description says the verb would succeed. Both can be true. What cannot happen is the acceptance being briefed as if it made can false. Accepted risk is still can. There is no fourth state. If you need a marker, put accepted in a note beside standing, with the name of the person who accepted and the date they agreed to look again. When that person has left, the acceptance is an orphaned decision sitting on a living verb. The account may have an owner. The decision does not.

Conditional Access report-only mode is a cousin of acceptance. Report-only tells you what would have happened. It is not enforcement. An exception process that files report-only as "control in place, monitoring" has documented a measurement and called it a boundary. Measurement is useful. It is the right step before you enforce, and only for the principals the feature can see. If the acceptance says workloads are covered and the principal is outside the workload limit, the acceptance is factually wrong, not merely bold. The owner of the answer owes the sponsor the correction, even when the acceptance has an executive signature. Signatures do not change the feature's limit.

Client secrets are the hole nobody files, because a secret does not look like a policy exception. User policies demand multi-factor authentication. The application authenticates with a secret and never meets them. There is often no ticket. The design of that row is the secret or the certificate, plus whatever app roles were consented. Say once, in the brief, that the user standard was never the standard for this row. Then stop calling it an exception. You do not return it to the user rule by clearing a checkbox. It changes when the permission changes, or when the credential is short-lived and minting the next one is gated. The Billing-Readers row is this shape in miniature: a readers name, a reset permission, no secret in the vault, and no ticket that calls it an exception. The name is the paperwork. The reset is the design.

Outside is not excepted

Registers of exceptions exist in many organisations and are already dead. They were filled during a project, exported to a spreadsheet, and left. Start from the controls you claim, and from the tickets that punched holes, and only then open the register to see what it missed.

For the neighbourhood, list the policies you are actually relying on in conversation. Multi-factor. A Conditional Access grant. Approval on a privileged role. A vault checkout. A leaver disablement. For each, export the exclusions, the bypass groups, the accounts marked emergency, the identities the workflow skips. Put each exclusion beside a verb if you have one, or mark the verb unknown and go and get it. An exclusion without a verb is a hole of unknown size. Sponsors hear "exception" as minor. The verb is what stops the hearing.

Then take tickets in the neighbourhood whose text contains temporary, exception, exclude, break-glass, vendor, migration, or the local words your engineers actually type. You will miss some. You will find enough. For each, ask whether the object the ticket created is still there. If it is gone, the ticket is history. If it remains, write the end date the ticket used, or write that it had none. Compare the date to today. Past, or absent, means you are not looking at an exception in force. You are looking at the design, and the ticket is the origin story. Origin stories go in the evidence pointer. They do not go in the state column as requested.

Join both lists to the Monday table. Some holes will match rows you have. Some rows will have no hole in the policy because they never went through a path the policy governs. Local accounts, app permissions, synced groups. Those are not exceptions to Conditional Access. They are outside it. Mark them outside, not excepted. The words lead to different remedies. An exception can be returned to the rule. An identity outside the rule needs the rule extended, or a different control, or an honest statement that no control is there. Pretending the second case is the first case is how a Conditional Access project reports success on a neighbourhood the policy does not touch.

The output is three piles, not a factory. Exceptions that are still bounded, with a future date and a living owner. Designs that used to be exceptions, dated or ownerless or both. Outsides that were being called exceptions in the register. The bounded pile is the only one that deserves the word exception in the next monthly brief. The design pile is standing access with paperwork. The outside pile is the gap, seen from the policy side.

Do not start a removal wave because a date has passed. Some designs are still the right operational choice, and removing them in a hurry is how break-glass gets deleted on a Friday and recreated wider on Saturday. This chapter's job is to stop paperwork lending a temporary word to a permanent grant. Once the word is honest, the owner of the fourth statement can brief the design pile as design. That brief is uncomfortable the first time, because it admits the target architecture is not what is running.

Entra will list exclusions if you export the policy rather than admire the diagram of who is covered. It will not label any of them as having become the design. The product's noun is exclusion, and exclusion sounds small. The size is the membership plus the verb. A policy that shows a single group exclusion is a pointer. If you brief the count of excluded groups and not the walked membership, you have counted footnotes. The governance platform often shows nothing, because the exclusion lives in a control it does not ingest. A campaign can certify the user who is excluded without ever loading the fact of exclusion. Joining the policy export to the identity, in the sheet, is the review that hole gets.

The vault, in the other direction, makes an account tagged break-glass look like a designed control. Sometimes the tag is the only designed part, and a second copy of the password sits where the tag cannot see. Checkout reports that show no use are not a description of how the account actually authenticates.

Resource-side holes rarely appear in any of the three. A storage account, a key vault, a database firewall, a SaaS admin allow-list. When you list the policies you are relying on, include the resource's own allow-list for the handful of wide resources. The identity stacks can be strict and the resource can be open. The fourth statement has to be allowed to name the resource policy as the winning description. If your exception work only exports Entra, you have decided in advance that Entra is where design lives.

A cutover needs a wide role for a weekend. The ticket is closed because the cutover completed, and closure is a workflow state, not a removal. A month later the role is still active. A reviewer who sees a serious group name, and not the chat, assumes a platform function and approves it. The weekend hole has been certified. What would have kept it an exception is a date on the object, and a state column that flips to standing when the membership outlives the window. The cutover team will say everything changed. The verb did not.

An exception granted to a group, a user-assigned managed identity, or a vendor account used by a rota spreads without a new ticket. The original approval named a purpose. The membership changes underneath. "Data-fix account for the billing incident" is specific. The group it points at is not, once twelve people can use the account and two of them have left. A user-assigned identity attached to a second and a third resource, because creating a new identity felt like waste, carries the permission to every attachment. If an acceptance names one resource and the identity is attached to five, the acceptance covers the story of the one. Walk attachments the way you walk group members.

Agents spread this way faster, because attaching a permission set is cheap. A sponsor for the first agent is not a sponsor for the next one that inherited the role. In the absence of an exit, every new agent that reuses the permission is another standing grant with an origin story about a single experiment. Keep them as separate rows if the owners might differ. A single acceptance called "AI agents" is the system-level acceptance already rejected.

Refuse the grouping until the permission set is on the table per agent, with the who-cell filled or explicitly empty.

A register that cannot save a row without a mitigating sentence will invent mitigations. Monitoring that nobody reads is not a control on the verb. Keep the piles in the Monday table, where a blank stays blank. Annual re-approval gives the exception a new date and the same shape. It does not ask whether the verb would succeed this morning. "Needed for the migration" in year three is folklore. Show the verb or stop calling the click a review. An emergency account excluded from every policy, usable every day, with an empty who-cell, is the design of emergency access.

"Inherited" is an origin, like a ticket. It is not a fourth pile called later. Holes are made faster than a register can be staffed, including holes that never met a ticket. A policy export will still show a Conditional Access exclusion that was a pull request. A secret in a pipeline will not show there at all. The outside pile is where those belong. A method that only reads tickets will miss the hole that was a change in a manifest. Age is how a hole becomes invisible to anyone who joined after the incident that justified it. The incident is forgotten. The hole remains.

A real gap, and a tooling excuse

You will be told that the design pile and the outside pile are tooling problems. The connector does not exist. The licence does not cover the policy. The governance platform cannot model the application. The vault cannot onboard what has no password. Some of those sentences are true, and specific enough to write on a row. Some of them are how a meeting ends while the verb remains. A real gap names a limit you can point at, and you can still say which object grants the verb. A tooling excuse uses the limit as a full stop.

Do not fold a documented limit into one product failure. Workload Conditional Access does not see every principal, and report-only does not enforce. A vault with nothing to hold is not a failure. A local account the identity provider was never shown is not an exclusion. Write the limit on the row, then read the assignment anyway.

Excuses are rarely lies. They are true answers to a smaller question: why is this not in the platform? Waiting on a licence when the verb is knowable without the control that licence buys. A roadmap written into the state cell, as if a vendor's quarter were a gate. Roadmap can sit beside standing, requested, and break-glass. It cannot replace them. Blame that stays in the past tense. Another offer of a single pane. A bucket called non-human, sold as the thing you have not bought, when the objects are already different and already listed. The Orchid baseline is not a SKU.

Take the row someone has called a tooling problem and judge it before the vendor's name is allowed to close the meeting. Would the verb succeed this morning if you bought nothing new? If it would, the missing product is not why can is true. It may be why one control is absent. Is the limit written where a stranger could check it, on a documentation page, a licence table, a connector matrix, or a hole in a policy export? A meeting does not bind the morning. If a person could fill the fourth statement with the stacks and the resource, and has not, you are looking at an ownership gap, a sight gap, or an exception that became the design. Say which. Some rows fail honestly. You cannot read a local store nobody will open. Write the name. If there is no name, do not fill the blank with a product. If you can infer a wide verb and cannot prove it, say inferred and stop. Leave the permission blank. An inferred wide verb can still be ranked, and the rank is a judgment under uncertainty.

Ask one more question of the quote. If you bought it, would the object be removed, or only become visible in a console? Visibility can feed the next review. It is not a close. A connector that aggregates an over-privileged application will display the over-privilege faithfully. Buy the wider view when the hand method has a denominator and you need a second neighbourhood. Do not buy it in place of a verb you have refused to write.

A row that survives those questions as a real control gap still needs a fourth statement: the verb, the object, and the limit, cited. Before any purchase you can still look, remove, or accept, and an acceptance needs a date and a living name. A Gantt chart does not fill an empty last clause.

A common excuse borrows a true limitation of one product to avoid work another product, or the resource itself, can already do. The governance platform cannot list the app role, so nobody lists it, while the directory can. The vault cannot express a managed identity, so the identity is called ungoverned, while the resource access list can. The workload limit leaves a class of principal uncovered, and the permissions on the service principal in your tenant are still visible. Waiting until you can govern a publisher's home tenant is a way to never look at your own consent. Write which stack was asked, and which stack can already answer. You are refusing to let the weakest relevant stack set the pace. Honesty about a limit is worth keeping. It becomes an excuse at the moment it ends the meeting.

The missing exit on an agent is not a limit of Entra, SailPoint, or CyberArk. The cell is empty because nobody specified the exit. A product that offers to govern agents does not write it for you. Cleartext in a manifest is a place, not a feature request. If you have opened the file, the copy in the file is the object. Once you can say the verb, over-privilege is not waiting on a pack of toxic combinations. That pack will recognise the directory roles everyone already knew were wide. It will miss the local admin that never met the identity provider. How wide is too wide is a judgment. Report-only, on a principal the feature can actually see, is the correct first state of a real con trol. Leaving it without a date is a design from this chapter, not a defect in the blade.

The Billing-Readers row is a bad alibi for a tooling story. Entra can see the group. The governance platform can see a label that says read. The vault has nothing it should hold. The verb, reset credentials on the billing user store, is knowable now. The limit line says none.

Sometimes the door really is locked. The application team will not show the local administrator list. The acquired company will not hand over the old directory. Do not recode a refusal as a technical gap so a tool can be asked to intrude. Write the refusal, the name, and the date. Unknown, with a name attached, is a management conversation. Ungovernable-until-we-buy is shopping.

Keep the three piles. Add, in one sentence, the real limit, or "none, the verb is knowable now". A roadmap slide cannot be checked against a tenant. A sentence about a documented limit can. A programme that buys the workload feature and points it at principals the feature excludes has bought a costume. Calling undone work a limit is how a backlog becomes destiny. A full licence would not have dragged an unused path into a control that never saw it. If a vendor says those cases are why you need their pane, ask whether the pane would remove the object, display it, or miss it.

The owner of the fourth statement keeps the duty. It does not move to whoever is running the purchase. Buying is not the sentence.