Tyler’s Tech CompanyTechnology, Handled PersonallyIndependent research and synthesis on how organizations document the systems, access, networks, vendors, dependencies, backups, recovery, changes, and incidents that keep work moving.
Read the findingsA practical synthesis, with the limits left visible.
The evidence supports a plain conclusion: useful documentation is not a binder, a wiki, or an asset list by itself. It is an owned operating system for finding what exists, understanding how it fits together, and completing high-consequence work without relying on one person’s memory.
This edition reviews government and industry standards, multi-organization surveys, public operating handbooks, and published practitioner accounts. It distinguishes empirical findings from TTCo synthesis, labels vendor-sponsored research, and does not pool incompatible samples.
Different studies. Different samples. A consistent reason to make documentation operational.
DORA 2021
About one quarter of respondents reported good-quality internal documentation. Teams with higher-quality documentation were 2.4 times more likely to report better software-delivery and operational performance. [1]
Association, not proof of causation; software-delivery population.Auvik 2021
In a 353-person network-management survey, 27% said their organizations rarely or never updated network documentation. The smallest organizations were the most exposed to never updating it. [2]
Vendor-sponsored network-operations sample.Auvik 2023
In a later survey of 4,500 IT professionals and decision-makers, 45% said they did not fully know how their networks were configured. [3]
Vendor-sponsored and not pooled with the 2021 sample.The pattern is less about having more documents and more about making the right knowledge dependable.
Useful documentation is findable, current, clear, and able to help a reader complete a real task. Page count is not a maturity measure. [1][18][23]
When ownership, vendor history, and recovery knowledge sit with one person, absence or turnover becomes an operational event. A small baseline should be proportionate, not optional. [2][5][22]
Named owners, visible review dates, and updates tied to system changes create a better defense against drift than periodic cleanup alone. [14][18][19]
Inventories establish what exists. Runbooks explain how to restore, change, escalate, or operate it—and should be tested by someone other than the author. [11][18]
Documentation must demonstrate that policies, reviews, recovery processes, and required controls exist and remain current. Regulation overlays size rather than replacing it. [13][20][21][24]
The strongest public practices make documentation part of change, incident, onboarding, and review workflows so the system improves while work is happening. [14][15][16][17]
This TTCo synthesis connects recommendations from the evidence into one operational picture rather than ten isolated lists.
Hardware, software, cloud resources, data-bearing media, location, owner, lifecycle, and approved status. [7][24]
Purpose, users, platform, environment, critical settings, support model, and lifecycle state. [4][13]
Users, roles, groups, privileged access, service accounts, recovery methods, and lifecycle ownership. [8][13]
Providers, circuits, equipment, topology, segments, Wi-Fi, remote paths, addresses, and configuration sources. [2][3][7]
Service scope, contract owner, support contacts, escalation path, renewal, data handling, and exit plan. [4][19]
Upstream and downstream services, data flows, authentication, integrations, and critical failure paths. [4][13][24]
Scope, frequency, retention, protection, location, monitoring, exceptions, and responsible owner. [9][11]
Priorities, recovery objectives, restore steps, alternate methods, validation, and escalation. [9][11][18]
Reason, approval, implementation, verification, rollback, affected records, and version history. [14][18]
Severity, roles, communications, timeline, impact, response, evidence, postmortem, and follow-up actions. [10][12][16][17]
Operational context connects the domains: business priority, data sensitivity, ownership, environment, risk, and recovery expectations.
Document what is true, link to detail, and make keeping it current part of the work.
Choose the authoritative record and link to it instead of maintaining competing copies. [14][15][18]
Give each document and operational domain an accountable owner plus a backup or escalation route. [18][19]
Show when content was last reviewed and when it is due again; increase cadence for critical or fast-changing systems. [10][14]
Write the desired outcome, prerequisites, permissions, steps, failure handling, validation, and escalation. [18]
Keep meaningful change records so operators can understand what changed, why, and by whom. [13][14]
Make updating the relevant record part of projects, configuration changes, onboarding, offboarding, and incident follow-up. [1][14][18]
Have another operator run important procedures and record the result; exercise recovery and incident plans on a defined cadence. [11][16][18]
TTCo guidance: document where a secret is controlled, who may retrieve it, and the recovery path—never embed live credentials in the runbook. [8][13]
Examples organizations have chosen to publish—not private observation by TTCo.
GitLab describes its public handbook as the current process and a single source to link, update, review, and build upon. Its published INSEAD interview excerpt also records the tradeoff: writing centrally can be slower in the moment but leaves a foundation for the next person. [14][15]
Google SRE’s public practice treats a postmortem as a written record of impact, response, causes, and preventive work. The account emphasizes blameless language, formal review, publication, and a searchable repository of prior incidents. [16]
PagerDuty publishes a reduced version of its internal incident-response documentation, covering severity, roles, call practice, response, postmortems, and training so operators are not inventing the process during an outage. [17]
AWS guidance calls for centralized, updated runbooks with outcomes, tools, permissions, errors, exceptions, escalation, ownership, and validation by another team member before the procedure is trusted. [18][19]
Knowledge lives with people; workarounds and vendor memory fill the gaps.
Critical ownership, access, vendor, backup, and recovery information can be found when needed.
Common tasks have owned, current runbooks that another capable person can follow.
Standards, reviews, lifecycle states, approvals, access, and evidence keep the system dependable.
Documentation changes with the environment, is tested in operations, and informs decisions.
Enough detail to understand what this study can—and cannot—support.
Evidence ledger
24 reviewed sources. Sample, sponsorship, organization type, and limits remain visible so unlike evidence is not flattened into one number.
Google Cloud DORA · 2021
Auvik Networks · 2021
Auvik Networks · 2023
National Institute of Standards and Technology · February 2024
National Institute of Standards and Technology · February 2024
Center for Internet Security · Current v8.1 guidance
Center for Internet Security · Current v8.1 guidance
Center for Internet Security · Current v8.1 guidance
Center for Internet Security · Current v8.1 guidance
Center for Internet Security · Current v8.1 guidance
National Institute of Standards and Technology · May 2010; updated November 2010
National Institute of Standards and Technology · April 2025
National Institute of Standards and Technology · September 2020; current release 5.2.0
GitLab · Continuously updated
GitLab · Continuously updated
Google Site Reliability Engineering · 2016
PagerDuty · Continuously updated
Amazon Web Services · Continuously updated
Amazon Web Services · Continuously updated
U.S. Department of Health and Human Services · Current guidance
National Institute of Standards and Technology · February 2024
Cybersecurity and Infrastructure Security Agency · March 2021
Google Cloud DORA · 2023
U.S. Department of Health and Human Services · August 2020
Documentation review
A focused review can identify the handful of records and runbooks that would reduce the most operational risk first.