---
title: Client Website Inventory Template for Web Agencies
description: Build one authoritative inventory of client websites, owners, domains, hosting, dependencies, critical journeys, monitoring, access, recovery, and support status.
source: https://pingvera.com/blog/client-website-inventory-template.html
---
# Client Website Inventory Template for Web Agencies

A client website inventory is the agency's authoritative record of every production service it supports: purpose, ownership, domain and infrastructure, application stack, critical journeys, dependencies, monitoring, recovery, access references, service class, and lifecycle status. It should answer operational questions during an incident without storing plaintext secrets.

The inventory is not the same as a list of monitors, hosting accounts, invoices, or portfolio screenshots. Those systems each show only part of responsibility.

## At a glance

For every site, record:

- stable internal ID and lifecycle status;
- client legal/operating entity and service owners;
- production, staging, and administrative URLs;
- business purpose and service class;
- domain, DNS, hosting, CDN/WAF, TLS, and email ownership;
- CMS/framework, runtime, database, repository, and deployment method;
- critical journeys and external dependencies;
- monitoring template, exceptions, and alert route;
- backup scope, RTO/RPO, and last restore test;
- secret-manager references and privileged roles;
- SLA/support schedule and time zone;
- known risks, expiry dates, and offboarding state.

## Minimum table

## Recommended data model

### Identity and service

- `site_id`;
- client organisation and internal client ID;
- service name, canonical URL, alternate domains, environment;
- purpose and criticality/service class;
- contract/support plan reference;
- support hours, time zone, and holiday calendar;
- active, onboarding, suspended, transfer, or archived status.

### Ownership

- client service owner;
- client emergency approver and fallback;
- agency service owner;
- technical owner;
- security/privacy escalation roles;
- vendor/integrator contacts;
- public status-page approval role.

### Infrastructure and application

- registrar, domain owner, renewal method, expiry;
- DNS, cloud/hosting, CDN/WAF, TLS issuance;
- CMS/framework/runtime/database;
- repository, production branch, deployment and rollback runbooks;
- scheduled jobs, queues, search, object storage;
- transactional email and identity provider.

### Business and dependencies

- critical journey IDs and success criteria;
- payment, tax, shipping, CRM, ERP, PIM, OMS, analytics, consent, and other dependencies;
- source of truth per dataset;
- business workaround;
- peak periods and regions.

### Operations

- monitoring template/version and check IDs;
- primary/fallback alert routes;
- severity mapping;
- maintenance-window rules;
- backup scope and retention;
- RTO/RPO and restore-test date/result;
- open risks, exceptions, expiry, and owner;
- last access review and next service review.

## Markdown record template

# WEB-[ID] — [service name]

Status: [onboarding/active/suspended/transfer/archived]
Client: [organisation]
Production: [URL]
Service class: [A/B/C/D]
Purpose: [value]
Support schedule: [value + time zone]

## Owners
- Client service owner: [role/contact reference]
- Emergency approver/fallback: [roles]
- Agency service owner: [role]
- Technical owner: [role]
- Security escalation: [role/process]

## Platform
- Domain/registrar/owner/expiry: [values]
- DNS: [provider/owner]
- Hosting/cloud: [provider/account reference]
- CDN/WAF/TLS: [values]
- CMS/framework/runtime/database: [values]
- Repository/deployment/rollback: [links]

## Critical journeys
- [CJ-ID]: [journey] — [success condition]

## Dependencies
- [system]: [purpose, owner, status link]

## Monitoring
- Template/version: [value]
- Check IDs: [list]
- Alert/fallback: [routes]
- Exceptions: [ID/expiry]

## Recovery
- Backup scope/retention: [value]
- RTO/RPO: [values]
- Last restore test: [date/result/link]

## Access
- Secret-manager collection: [reference]
- Privileged roles: [list]
- Last review: [date]

## Risks and decisions
- [risk, impact, owner, decision, expiry]

CSV header for a starter spreadsheet
site_id,status,client,service_name,production_url,purpose,service_class,support_schedule,time_zone,client_owner,agency_owner,technical_owner,domain_registrar,domain_owner,domain_expiry,dns_provider,hosting_provider,cdn_waf,cms_framework,runtime,repository,critical_journey_ids,monitor_template,alert_route,backup_scope,rto,rpo,last_restore_test,last_access_review,risk_count,next_review

Keep multi-value operational details in linked records once the spreadsheet becomes difficult to review. The inventory should not become a giant unstructured cell.

## Data ownership and update events

Assign one inventory owner. Require updates after:

- onboarding or contract change;
- domain, DNS, hosting, CDN, CMS, or vendor change;
- new business journey or market region;
- monitoring template change;
- incident revealing an unknown dependency;
- restore test;
- privileged access change;
- client contact change;
- suspension or offboarding.

Automate discovery where useful, but do not overwrite reviewed ownership or accepted-risk decisions blindly.

## Validation rules

Examples:

- active site must have client and agency owners;
- Class A/B site must have at least one critical journey;
- domain expiry must be known or explicitly marked unavailable with an owner;
- every privileged access reference must have a last-review date;
- active monitoring template must exist and match the service class;
- exception must have approver and expiry;
- archived site cannot remain in on-call routing unless justified;
- restore status must be `tested`, `partial`, `failed`, or `untested`, never simply `yes`.

## Example portfolio questions

With a structured inventory, the agency can answer:

- Which high-criticality stores have no end-to-end checkout or form check?
- Which domains expire within 60 days and are owned by individuals?
- Which active clients have an overdue access review?
- Which sites depend on the same hosting, DNS, plugin, or email provider?
- Which recovery tests missed RTO?
- Which exceptions expire this month?
- Which former clients still have monitoring or privileged access?

## Common mistakes

- storing passwords in the spreadsheet;
- creating separate conflicting inventories for sales, hosting, and support;
- using a URL as the only identifier;
- omitting lifecycle status;
- storing a person's name without a role and fallback;
- recording “backup enabled” without restore evidence;
- allowing exceptions with no expiry;
- never reconciling the inventory with billing, monitoring, and access systems.

## FAQ

### Should the inventory live in a spreadsheet, database, or CMDB?

Use the simplest tool that supports ownership, validation, history, access control, and automation needs. The model matters more than the brand.

### Who should be allowed to edit it?

Limit editing to operational owners and use change history. Broader teams may need read access with sensitive fields separated.

### How often should it be reviewed?

Update on change and run a portfolio review at least quarterly; critical renewal and ownership fields should be checked more frequently.

### Can monitoring populate the inventory automatically?

It can discover technical fields and check state. Human-reviewed business purpose, responsibility, SLA, and accepted risk still need authoritative ownership.

## Sources and further reading

- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
- [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final)

Reviewed: **8 August 2026**.

Next: [Web agency access control matrix](https://pingvera.com/blog/web-agency-access-control-matrix.html) and [managing multiple client websites](https://pingvera.com/blog/manage-multiple-client-websites.html).

Pingvera can contribute monitor IDs, status, observed domains, TLS data, and external evidence. Keep the inventory broader than any monitoring vendor.