Two useful views
An asset is anything that has value to a stakeholder. It can be data, service availability, a cryptographic key, reputation, safety, a business process, or the ability to recover. A protected resource is the object or service against which an access decision is made. One resource can affect several assets.
Find the real value
Begin with harm, not inventory labels. Ask what an attacker could read, change, stop, misuse, or make untrustworthy. Include derived data, credentials, policy, logs, backups, and control interfaces. State whose value is at risk and why.
Give resources stable boundaries
Name resources at the level where policy can be enforced: an application route, API operation, record, queue, database, or administrative function. A broad label such as "the platform" hides distinct actions and protection needs. Connect each resource and action to the assets it can affect.
Failure and residual risk
Asset lists become stale. Teams often omit control-plane access, metadata, availability, recovery material, and indirect dependencies. A gateway can protect a route while the application exposes the same asset through another API or background job.
Pomerium boundary
Pomerium route policy can control access to a named upstream and request path. The application must enforce access to records and business actions inside that upstream. The deployment must identify and close alternate network or application paths to the same assets.
Evaluation checklist
- Can each asset be tied to a stakeholder and credible harm?
- Does each access rule name a resource and action at an enforceable level?
- Are keys, policy, logs, backups, and recovery systems included?
- Can another route, API, job, or network path reach the same asset?
- Does the owner review the asset map after architecture or business changes?
