You Have Already Tiered the Estate. Write Down the Basis Before Somebody Asks.

You have already tiered the estate

Look at where application security effort landed this quarter. Some repositories are scanned on every pull request, have an owner who answers, and get triage hours from a person whose name you know. Some get a nightly scan nobody opens. The rest get whatever the default policy does. That distribution is a tiering decision, already made.

It was made by onboarding order, by which engineering directors were in the room during the pilot, by which repositories had a pipeline that could be instrumented in an afternoon. Each was a sensible local call. Stacked up, they amount to a budget allocation whose only justification is the order in which things happened.

A platform is built and priced to generalize across every customer, which is what a platform is for. Deciding which parts of your estate it should cover is estate-specific work, and it sits with the people who own the estate.

Budget for equal attention across the whole estate is a hypothetical, and everyone in the conversation knows it. What the program needs is a written basis for spending less on the rest of it. Where that basis is absent, every scope discussion restarts from first principles and gets settled by whoever carries the most standing in the room that day. Four signs say you are in that position.

• Coverage grew in onboarding order, and the order was set by which teams already had a working pipeline
• A system is in scope because it was in the pilot, and it was in the pilot because it was easy to instrument
• Two systems with comparable exposure get different treatment, and the reason lives in somebody's memory of a meeting
• The same scope argument comes back every quarter and is settled the same way, by seniority

Criteria that survive a full-estate sort

Criteria that read well in a planning document behave differently once they have to sort roughly 6,300 rows, which is the size of the estate CWS discovered before any strategy was written against it. The ones that failed did so immediately.

Self-reported business criticality went first. Ask teams to rate their own systems and the ratings pile up at the top, because the person filling in the form understands what a low rating does to their headcount next year. The responses honestly reflect how people are incentivized to answer, which makes them a good map of incentives and a weak sort key.

Repository size and last-commit recency failed together, because both measure engineering activity. A shared authentication library can sit untouched for a year and still stand in the path of every service that authenticates a user. An internal tool with three users produces commits every day. Sorting on either axis puts those two in the wrong order, with great confidence. Language sorted the estate by what was straightforward to scan, a good input to sequencing and a weak input to priority.

The criteria that survived the volume shared one property. Each could be read straight out of a system of record the organization already maintained for another purpose.

• Reachability read out of deployment configuration and load balancer rules, which is a fact about the running system
• Regulated data or a payment path in the runtime, traced along the data flow the system executes
• Dependency fan-in, meaning how many internal services import this code, computable from package manifests you already hold
• Whether an artifact built here ships outside the company and runs on machines you do not control
• Whether a named human owner exists, since an unowned repository still tiers on its exposure and carries owner reconstruction as the first task in whatever tier that exposure earns it

The criteria that survived were the ones nobody had to be asked about.

The written basis is the deliverable

The ranking is an output and it ages. The document explaining how the ranking was produced has to still be readable in eighteen months by somebody who joined afterwards, and it is the thing an auditor asks for. It runs to a page or two.

The NIST Secure Software Development Framework assumes a tiering exists and leaves its construction to you. OWASP SAMM goes a step further and asks for an application risk profile under its design practices, which names the artifact and leaves the criteria to the organization that has to defend them. The written basis is where that work lives.

Record the criteria you considered and set aside, with the reason for each. It is the cheapest page in the document and the one that carries the most weight later. An auditor who can see that self-reported criticality was evaluated and set aside for a stated reason is looking at a method. With that page absent, the same auditor is looking at a list of repositories and an assertion.

Threshold ownership, exclusion records and event-driven re-scoring are CWS positions, offered as positions. A threshold with an author can be revisited by going back to the author and asking what has changed since. An anonymous threshold gets argued from scratch every time it costs somebody something. Five entries make up the record.

• The criterion, written so somebody outside the security team can apply it to a repository they have never seen
• The threshold, with the actual value in it, since a criterion with no value attached will be read differently by every reader
• The system of record each criterion is read from, and the date of the reading
• The name of whoever approved the thresholds and the date they approved them
• The criteria that were considered and set aside, each with its reason

Three rooms where it gets challenged

A tiering decision gets tested in three rooms, and the same document has to work in all of them. The three people asking want different things from it.

The auditor is testing for method and consistent application. They want evidence that a basis existed before the decisions were taken, that it was applied the same way across the estate, and that departures were recorded as exceptions carrying a reason and a name. Where you drew the line is your judgment to make. Whether a line existed at all is the thing under test.

The board member is asking about the part you have decided to leave mostly alone. What answers that is a description of the residual: what the lower tiers still receive, in terms of what runs, on what schedule, and who reads the output. A tier-down that reads as zero coverage will be recorded as an unmanaged risk, and it should be.

The engineering director whose repositories moved down is asking a fairness question with a practical one inside it. Their systems get less of your attention and they want to know what that means the week something goes wrong. Handle this before publication. The criteria should be visible to them, and the route back up should be a criterion they can meet on their own schedule.

• Keep an exceptions register. Repositories get moved by hand, and an exception holds only while it carries a reason and a name
• State the floor for each lower tier in operational terms: what runs, on what schedule, and who looks at the output
• Publish the promotion criteria alongside the tiering, so the route up exists before anybody has to argue for it
• Walk engineering leadership through the readout before the risk committee sees it, so the first time they read it is with you and with time to argue

Nobody accepts a lower tier that has never been described to them.

Keeping it true after publication

Tiering fails quietly after publication, because the estate keeps moving and the document stops. A service picks up a payment path in a release nobody flagged. An internal library gets published to a public registry. An acquisition arrives with its own source control tenant. From the day of each change the repository sits in the wrong tier, and the document says otherwise until somebody re-runs it.

An annual review catches this late by design, since the calendar runs on its own schedule and the estate runs on events. Tie the re-score to events that already produce a record somewhere. Each of those events lands in a system today, so the re-score becomes a query.

The other way it comes apart is size. Six tiers and eleven criteria describe the estate beautifully, and the team that has to run them week after week is the constraint. Cap the tiers at the number of distinct treatments you can staff and describe. Where two tiers get the same treatment, they are one tier with two names.

The 6,300 repository estate became workable at the point where the criteria that sorted it carried a name and a date, and where the engineering leaders affected by the sort had read those criteria before it ran. The count made the conversation possible. The written basis is what let it hold.

• Attach the re-score to events that already generate a record: acquisition close, a repository changing visibility, a new data classification, a deployment change that alters reachability
• Keep the tiering as a query against the inventory table, so next year's re-baseline is small work
• Date every published version and keep the previous ones, because the audit question is what the basis said at the time a given decision was taken

Count your distinct treatments first. That number is the number of tiers.