Security Exception Requests: Approvals That Hold Up When Approvers and Controls Change

Exceptions approved in chat and recorded somewhere else

Product teams ask for security exceptions all the time: a legacy service that cannot use the new TLS settings yet, a data job that needs an egress rule, a repository that cannot pass a scan until a dependency is replaced. Each request is a Notion page with its control, asset, compensating control and expiry date. The asset's owner and data class live in the Airtable inventory, and the exception policy and authorized approver list are in Google Drive.

Approvals are where it gets loose. Approvers answer in Microsoft Teams, often with one word, and that message is taken as the approval. Sometimes it came from someone who is not authorized for that control class. Sometimes the approver has since left the company. And when security reclassifies a control, exceptions granted under the old class keep their old status because nobody re-derives them.

Who works in the room

Requests come to Ada by default; anything about who approved what goes to Fin. Fin reads Teams through the security lead's own account, checked on every call, and treats each approval message as evidence to verify, not a decision. Ada updates the Notion pages under a lasting grant the security lead approved, after each change is approved in the thread. When an approval does not hold, Fin mentions Ada with the request IDs and the reason, and Ada leads from there.

A week in the exception register

The register is reviewed weekly, and every disposition names the policy rule, the asset record and the approval evidence it rests on.

When an approver leaves or a control changes class

An approval is only as good as the person who gave it. When an approver leaves, Fin lists every pending request they approved, and those approvals stop counting; the requests go back to awaiting approval rather than going through on a technicality. Exceptions already approved before the departure keep their status, and their next renewal decides them. Each check keeps a run history, so the register can always show which message an approval rested on.

Reclassification is the opposite problem: one change that touches a whole group. When security architecture moves a control into a stricter class, Ada re-derives every exception under that control, and only those. A few lose an approval that came from someone authorized only for the old class. The thread shows the before and after for each row, so the security lead can approve the changes as one decision.

What the checks catch

• An approval message in Teams from someone who is not on the authorized list for that control class
• A pending approval from an approver who has since left, which no longer counts
• A new co-signing rule applied to already approved exceptions, when it covers pending requests only
• Exceptions under a reclassified control left at their old status, or exceptions under other controls re-derived by mistake
• A renewal requested for an asset whose data class changed in Airtable after the exception was granted

What stays with people

• Approving every exception, which only an authorized approver can do
• Approving each disposition before the Notion page changes
• Naming a replacement approver when someone leaves
• Deciding whether a compensating control is strong enough

Integrations in this workflow

Kylon is not a governance, risk and compliance suite, and it does not replace one. It sits across the register, the inventory and the chat where approvals happen, and holds the checking between them.

• Airtable
• Google Drive
• Microsoft Teams
• Notion
• Slack

• Notion holds the exception register, one page per request with its control, asset, approvals and expiry
• Airtable holds the asset inventory, with each asset's owner and data class
• Microsoft Teams is where approvers give their approvals, which Fin reads as evidence to verify
• Google Drive keeps the exception policy, the control classes and the authorized approver list
• Slack is where engineering teams ask about their requests and receive follow-ups once the security lead approves them

Where to start

The pending requests in one control class are enough for a first week. Connect the Notion register and the Airtable inventory, and open the room guidelines with this rule: an approval in chat is evidence, it counts only if the approver is authorized and still here, and the security lead approves every disposition.

“A one-word reply in chat is still how approvers say yes. The difference is that someone now checks who said it.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.