skip to content

Nobody will sign for denying unclaimed extranet subjects an adversary may already be using — how do you force that decision to an owner?

level: principalimportance: nice to knowfreq 33%

answer

  1. only one option currently needs a signature
  2. write the status quo up as an acceptance
  3. dated, named, expiring
  4. shrink the worst case before asking again
  5. escalate to the contract owner, not IT

basics

~10 s

Stop asking for a signature on a setting; put a dated, named risk acceptance under the current allow instead. Once staying open needs an owner and an expiry, the decision makes itself.

solid answer

~50 s

The deadlock exists because only one option looks like a decision. Deny needs a signature; allow is the status quo and needs nothing. Break that symmetry first: write the current allow-by-default up as an explicit, dated risk acceptance naming the unclaimed subjects, and route it for signature. Almost nobody signs it, and the deadlock resolves itself. Then make the choice cheaper on both sides — enforce first where the caller list is already owned so you have evidence enforcement is survivable, and pair denial with a fast, expiring break-glass so being wrong costs a ten-minute grant rather than a quarter's revenue. Escalate unclaimed entities up the commercial line, not the technical one: the business unit that owns the partner contract owns the integration. And put an integration-registration clause into partner contracts at renewal so the next generation of this problem has an owner by default.

go deeper

for a junior

Know that whether unknown entities are allowed or denied is ultimately a business decision with a named accepter, not something an engineer sets alone on the day.

for a middle

Be able to explain why the status quo wins by default: changing to deny needs an approver, and leaving allow in place needs nobody, so drift looks like caution.

for a senior

Show you would shrink the worst case before asking again — phased enforcement on owned destinations, a staffed break-glass with automatic expiry, and a rehearsal that turns prediction into observation.

for a principal

Own the forcing mechanism: document the current allow as a dated risk acceptance and route it for signature, agree an owner-of-last-resort rule before the deadline, escalate along the contract line, and add registration obligations at renewal.

## Why the deadlock is structural, not personal On enforcement day for a partner extranet, the set of subjects that no rule names and no team claims still contains things that move money. The application owners will not sign for denying them, because they cannot prove the entity is unused and they will own the 02:00 outage. Security will not sign for continuing to allow them, because that is the exact hole the programme was funded to close. Neither refusal is unreasonable, and the result is that the default stays whatever it was — set years ago by someone who was not making a risk decision at all. The structural cause is an **asymmetry in what counts as a decision**. Turning the catch-all to deny is a change: it needs a ticket, an approver and a name. Leaving it as allow is the absence of a change: it needs nobody. So the organisation drifts toward the option that requires no signature, and calls that outcome caution. ## Move one: make the status quo require a signature too The highest-leverage act is not technical. Write the current posture up as what it is — a **risk acceptance**: "we permit any subject we cannot name to reach these resources; here are the resources; here is the list of unclaimed subjects observed in the last quarter; this acceptance expires on this date." Route it to the person who would have had to approve a deny. Two things happen. Most of the time nobody signs, and the deny suddenly acquires its approver. Occasionally somebody does sign, which is also a good outcome: the risk is now owned, dated and reviewable rather than ambient, and you have a date to work back from. The worst thing you can do is nothing while continuing to escalate verbally. Verbal escalation leaves the asymmetry intact. ## Move two: change the price of being wrong A sponsor refusing to sign is usually refusing a specific worst case — an unknown, revenue-bearing integration failing overnight with nobody able to fix it. Shrink that case: - **Break-glass with an expiry.** An on-call engineer can grant a named subject access in minutes, and the grant auto-expires in hours or days. Being wrong now costs a phone call, not a quarter. - **Phase by destination sensitivity.** Start with resources whose caller list is already complete and owned. Each successful phase is evidence, and evidence is what a reluctant signer is actually short of. - **Announce a denial rehearsal.** A short, scheduled deny during a low-risk window, with the break-glass staffed, converts the argument from prediction to observation. What breaks, breaks in daylight with the right people watching. ## Move three: escalate along the commercial line, not the technical one An unowned integration in a partner extranet almost always has a commercial owner even when it has no technical one: someone signed the contract that the integration serves. Escalating within IT produces the honest answer "we do not know what this is." Escalating to the business unit that owns the supplier relationship produces either an owner or a genuine "nobody needs this", and both are progress. The forcing mechanism that works is an **owner-of-last-resort rule agreed in advance**: any subject unclaimed by a stated date is owned by a named default owner — often the head of the function that owns the extranet — and that owner decides its fate. This converts "nobody will sign" into "one person's inbox", which is a solvable problem. It only works if it is agreed before the deadline, because agreeing to be the default owner in the abstract is far easier than agreeing to be it for a specific outage. ## Move four: fix the next generation contractually The estate acquired these entities because nothing in the onboarding path created an inventory record. Add an integration-registration obligation to partner contracts at renewal — named technical contact, declared endpoints, declared schedule, annual re-attestation — and make issuing a credential conditional on it. This does nothing for today's unclaimed pile, and saying so plainly is part of the answer; it is what stops you being in the same room in three years. ## What to report upward Put the two costs in the same units. The deny side is bounded and estimable: a number of unclaimed subjects, a worst-case interruption measured in hours, a staffed break-glass. The allow side is unbounded and continuous: any of these subjects is a usable path for an intruder, with no review, no expiry and no alerting, for as long as the acceptance stands. Executives reliably choose the bounded cost once someone has actually bounded it — and refusing to bound it is what has kept the default unsigned.

  • What if the sponsor does sign the risk acceptance for allow-by-default?
    That is a legitimate outcome and better than the drift you had. The risk is now named, owned, scoped to specific resources, and expiring on a date. Use the interval to shrink the unclaimed set and to build the break-glass, so that at renewal the same signature is asked for against a smaller list and a cheaper worst case.
  • How do you set the date by which an unclaimed subject gets a default owner?
    Work back from a business cycle rather than a convenient quarter-end: give claimants at least one full cycle plus a reminder, so a quarterly integration's owner has actually had a reason to notice it. Announce the default-owner rule at the start of that period, not at the end, because people accept the role in the abstract far more readily than for a named outage.
  • The partner refuses to identify their integration's technical contact. What then?
    That is a commercial conversation, not a technical one, and it belongs to whoever owns the contract. In practice the leverage is credential issuance and renewal: access continues only against a named contact and declared endpoints. If the partner will not provide one, the honest position is that the organisation is accepting risk on their behalf, and that acceptance needs the same signature as any other.

saying these in an interview costs you the question

  • Escalates verbally without ever making allow require a signature
  • Presents deny as a purely technical change with no owner
  • Flips the whole estate on one date to force the issue
  • Leaves risk acceptances undated and unowned
  • Escalates only within IT for a commercially owned integration
  • Quantifies the outage cost but calls the breach cost unquantifiable

context