nobody remembers why that rule exists

A new network engineer at a 250-person company spent her first month familiarizing herself with the environment. Part of the familiarization was reading through the firewall rule base on the company’s primary perimeter. The rule base had 847 rules. The engineer began reading them, top to bottom, making notes on each.

Most rules had descriptive names and comments. “Allow inbound HTTPS to production web servers.” “Block outbound SMB to the internet.” “Allow management traffic from admin subnet to network devices.” These were easy to understand.

A meaningful fraction of the rules were less clear. “Temporary rule - do not remove until Martinez confirms.” “Change 2021-07-23 ticket #4471.” “Allow 10.2.14.7 to 45.61.78.22 port 8443.” No context. No description. No indication of who owned the rule or why.

The engineer asked her manager who Martinez was and what the ticket numbers referenced. Martinez had left the company two years earlier. The ticketing system had been migrated to a new platform in 2023, and the old tickets were no longer accessible. The comments referenced a system that no longer existed.

She asked about the unexplained IP-pair rules. Her manager explained that each of those rules had been added during a specific incident or project and had never been removed. Some of them might still be necessary. Some were definitely not. Determining which was which would require a careful investigation of each rule, one at a time, with the risk of breaking something legitimate if a needed rule was removed.

She had encountered the last-admin problem. The person who understood the original reason for each rule had left the company. The rules remained, authoritative, enforcing behavior that might or might not be justified. The organization had inherited the rule base without inheriting the context for it.

This pattern applies to many things beyond firewall rules. Identity grants made for reasons that are no longer remembered. Configurations on systems that nobody currently at the company set. Automation scripts running with credentials and permissions that nobody can explain. Integration arrangements with external partners that predate current leadership.

This essay is about that inheritance. Why institutional memory fades, what it leaves behind, and what the cleanup looks like when the person who would have known is no longer available.

the context fades faster than the artifacts

The specific pattern: an artifact persists in a system, and the context for why it exists fades over time.

The firewall rule stays in the rule base. The original author is gone. The ticket they referenced is in a system that was migrated. The manager they reported to has also moved on. The business context, the specific customer, project, or incident that required the rule, is no longer available.

The same pattern applies to identity artifacts. A service account exists in Active Directory. The person who created it is gone. The automation it was created for was decommissioned. The credentials for the service account are stored somewhere, still being used by something. Nobody can explain why the account has the permissions it has.

The pattern applies to configuration. A setting is enabled on a server. The commit that enabled it is years old. The engineer who made the change is at a different company. The reason the setting was changed is not in the commit message, because the commit message said “fix config” and the real reason was in a chat thread that no longer exists.

Context decay is a property of organizations over time. People leave, documentation drifts, systems get migrated, memory fades. The artifacts they created remain in place, silently continuing to do whatever they were set up to do, without the context that would allow anyone to evaluate whether they should still do it.

the asymmetry of keeping versus removing

When facing an artifact of uncertain purpose, the decision to keep it is lower-risk than the decision to remove it. Keeping the artifact means accepting that it continues to do whatever it does. Removing the artifact means taking responsibility for whatever breaks when it’s removed.

The asymmetry produces a default. Artifacts of uncertain purpose stay in place. The cost of removal is borne by the remover in the present. The cost of keeping is diffuse and deferred.

For an individual change, one firewall rule, one service account, one configuration setting, the asymmetry is small. The risk of breaking something is real, and keeping the artifact is usually the right call if no current reason to remove it has emerged.

For a system of many artifacts over many years, the asymmetry compounds. The cumulative weight of kept-because-unsure artifacts is a significant portion of the overall configuration. Cleaning up requires the active decision to remove, applied systematically, which is the harder direction.

Organizations default to accumulation. The accumulation is visible in every mature system, the firewall rule base, the Active Directory group list, the Salesforce permission sets, the CI/CD configuration. Each shows ten years of additive decisions with relatively few subtractive ones.

why the rule nobody understands stays

removing it

visible risk

• If something breaks, you broke it
• Needs investigation first
• Nobody thanks you when nothing happens

keeping it

invisible cost

• Nobody is blamed for leaving it
• The risk grows quietly
• The next person inherits even less context

the person who knew leaves

The specific failure of institutional memory is the departure of the person who understood the context. For some artifacts, one person held most of the context. When that person leaves, the context is gone.

This is common. A single person becomes the expert on a specific system, set of rules, or area of configuration. The expertise accumulates over years. When the person leaves, through departure, retirement, reorganization, or death, the expertise leaves with them.

The organization’s response options are limited. Written documentation, if it exists, is partial and often out of date. The systems themselves don’t tell you why they’re configured the way they are. Asking adjacent people usually yields partial context at best.

The practical default is to continue operating the system as is, with the understanding that changes are risky and should be approached carefully. Over time, the system accumulates more layers of configuration from successor admins, each of whom adds context for their changes but not for the pre-existing state.

Five years after the original expert leaves, the system is a palimpsest. Original configurations from the expert’s era, still in effect, without remembered context. New configurations from subsequent admins, layered on top, with their own partial context. The original and the new are indistinguishable in the system’s current state.

the archaeological approach

Some systems are amenable to archaeological investigation. Logs, change history, and audit trails can reveal when artifacts were created and by whom, which gives partial context.

Git history is the most useful example. A configuration in a git-tracked file can be traced back to the commit that introduced it. The commit has an author, a date, and (if the commit message is useful) some rationale. Even uninformative commit messages give you the timeframe, which helps narrow down the context.

Active Directory has audit logs for object creation, though the retention varies. Identity providers like Okta and Entra retain activity logs for configurable periods. Firewall management consoles typically log rule changes. Most systems have some form of audit trail.

The archaeological approach is to investigate each uncertain artifact using whatever audit trail exists, correlate with other sources (tickets, emails, chat logs if archived), and reconstruct enough context to make a decision.

The approach is labor-intensive. For a single artifact, the investigation might take an hour. For a rule base of 847 rules, a thorough investigation is weeks of work.

Most organizations don’t do this thorough work. The cost is high and the benefit is uncertain (you might learn that most of the artifacts are still needed, in which case the work produces no net simplification).

The compromise is to archaeologically investigate the artifacts that matter most, the high-privilege ones, the ones that affect production systems, the ones that involve external parties, and accept ambiguity on the rest.

the test-and-remove approach

A more aggressive cleanup strategy: assume the artifact isn’t needed, remove it temporarily, and see if anything breaks.

For firewall rules, this is the “shadow” test, introduce a logging rule that would match the existing rule’s traffic but take no action, run it for a period of time, and see what actually hits it. Rules with no hits can likely be removed. Rules with hits are still needed, and the hit pattern tells you what for.

For service accounts, this is the disablement test, disable the account for a specific period, see what breaks, re-enable if anything important stops working. The test is risky and requires rollback capability, but it produces definitive answers.

For identity grants, this is the reduction drill mentioned in an earlier essay, suspend non-essential access for a period and observe what complaints arise.

The test-and-remove approach produces more removals than the archaeological approach, because the test is the definitive evidence rather than inferred context. It is also higher-risk, because the test period might coincide with a rare use case that isn’t noticed during the test.

For systems where the test can be controlled and rolled back quickly, test-and-remove is usually the more efficient approach. For systems where testing is risky or slow to roll back, archaeological investigation is safer.

deciding what to do with an artifact nobody can explain

1. 1do you know what it's for?Yes: write down the context for the next person.
2. 2is it high stakes?Yes: dig through logs, tickets and old chat history first.
3. 3is a test safe?Yes: disable it for a set period and watch what complains.
4. 4otherwiseAccept it for now, and write down why.

the documentation that would have helped

A specific frame for thinking about this: the artifacts that don’t have context when you inherit them are artifacts whose creators didn’t document them.

Documentation at the time of creation is cheap relative to investigation years later. A commit message that explains the why, a comment on a firewall rule that references a ticket, a README in a service account’s home directory, all of these preserve context for future readers.

Most creators don’t document at the time. Not because they’re lazy, but because the context is obvious to them in the moment, and the future readers feel hypothetical. The documentation cost is incurred in the present for a benefit that accrues to unknown future people, which is a bargain most people intuitively reject.

Organizational discipline to force documentation is one of the higher-leverage investments a team can make. Requiring a rationale in every commit message that changes configuration. Requiring a ticket reference on every firewall rule. Requiring a description and owner on every service account.

The discipline slows things down slightly in the present. The payoff, in reduced investigation cost for future inheritors, is large.

Most organizations don’t have this discipline. The organizations that do have it typically established it after experiencing a major incident where missing documentation made the response harder. The incident is the forcing function.

the post-departure checklist

A specific organizational practice worth adopting: the post-departure review.

When a key technical person leaves the company, the review identifies the systems and artifacts that were primarily under their ownership. For each one, the review asks: who is the new owner? What context needs to be transferred? What artifacts should be documented before the departing person leaves?

The review is best done before the person’s last day, with the person’s participation. They can walk through the systems and explain the context. The walkthrough is recorded (literally, as video, or in a detailed document).

Most companies don’t do this systematically. Exit processes focus on HR logistics, equipment return, and access revocation. The technical knowledge transfer is ad hoc. Successors inherit systems without inheriting context.

The companies that do this systematically accumulate institutional memory faster than those that don’t. The post-departure review is small, bounded, and produces documentation that serves for years.

Implementation is straightforward: add a “knowledge transfer” task to the standard exit checklist. Schedule a one-hour or multi-hour session with the departing person and their successor. Record the session. Store the recording somewhere findable.

the specific exercise

If you have inherited any system with artifacts of uncertain purpose, here is the exercise.

Pick one specific category of artifacts, firewall rules, service accounts, integration credentials, group memberships, whatever you’re uncertain about. Pull the full list.

For each artifact, categorize: do I know what this is for? Yes or no.

For the artifacts you know about, document the context briefly. The documentation is for your successor.

For the artifacts you don’t know about, decide on the investigation approach. Archaeological for the high-stakes ones. Test-and-remove for the ones where testing is safe. Accept-as-is for the ones where the investigation cost isn’t worth it.

Do the investigation. Document what you learn. Remove what you can confidently remove.

This becomes your institutional memory. Other people who inherit the system after you will have access to what you documented. The chain of context is preserved.

The last admin is gone. You can’t bring back their knowledge. You can prevent the next admin from having the same problem, by documenting what you do while you’re there.

The firewall rule doesn’t know why it exists. The service account doesn’t remember its creator. The permission grant is silent about its origin. You are the only one who can record the why. Record it now. The next person inheriting will thank you.

This is the last essay in the Access Creep series on the specific patterns of access accumulation. The patterns are familiar to anyone who has worked in a mature enterprise. The fix for each of them is straightforward to describe and expensive to execute. The organizations that will handle the next decade of security well are the ones that execute the fixes, one at a time, until the access graphs they operate actually reflect the intent of their policies.

The accumulation continues if nothing actively reverses it. Active reversal is the work. Nothing else will do it.