Guided introduction · v1.2 public draft
Start with TrustSurface.
TrustSurface is a governance framework for identifying the digital systems and dependencies through which trust is experienced, assessing defined Trust Signals using attributable Evidence, and turning the resulting posture view into action and governance.
This page teaches the idea before asking you to read the formal framework. Follow the seven stages in order, or use the index to jump to the question you need answered.
The problem
Security posture is not the whole digital-trust picture.
Organisations already invest in cybersecurity, compliance, architecture, and technology operations. Those disciplines are essential, but stakeholders do not experience most internal controls directly. They experience domains, email, identity flows, websites, services, outages, and third parties.
That creates a recurring governance problem: internal protection may be strong while trust-relevant conditions at the digital edge remain weak, inconsistent, unknown, or poorly governed. TrustSurface calls the difference between the trust posture an organisation intends (or believes it has) and the posture actually signalled by observable evidence a Trust Signal Gap.
A simple example: organisational email
A mature security program does not, by itself, answer whether:
- the organisation's primary domain can be impersonated;
- all legitimate sending platforms are known and governed;
- current evidence supports the claimed email-integrity posture; or
- changes to senders can quietly weaken that posture later.
The TrustSurface move: make those trust-relevant conditions visible enough to assess, act on, and govern.
Your Trust Surface
Start with the systems and boundaries through which trust is experienced.
A Trust Surface gives the problem a boundary. It lets you move from a broad discussion about “digital trust” to a defined set of systems, services, dependencies, relationships, and observable conditions that can actually be examined.
The collection of digital systems and observable signals through which stakeholders experience and judge the trustworthiness of an organisation's digital presence.
Picture one ordinary interaction
You receive an email claiming to come from an organisation and follow it to a digital service. You do not inspect the organisation's cyber program. You encounter its Trust Surface:
- the sender and domain;
- the email-authentication conditions behind the message;
- the link destination and DNS path;
- the website, identity flow, and certificate behaviour;
- the platforms and third parties involved in delivering the service; and
- what the organisation communicates when something fails.
The scope can be organisation-wide, but it does not have to be. A single service, domain namespace, email environment, or vendor dependency can be a valid bounded starting point.
Six domains
Use six domains as a map of the digital environment.
TrustSurface uses six domains to make distributed ownership and dependencies discussable. They are analytical and governance views, not organisational silos. A real system may span several of them at once.
Do not force a system into one box. An email-platform decision can affect Email Integrity, Domains & DNS, and the Third-Party Ecosystem at the same time. The overlap is part of the model.
Signals and Evidence
Define the condition first. Then gather Evidence to assess it.
This is the key distinction in TrustSurface. A Trust Signal is a defined trust-relevant property, behaviour, or condition of a Trust Surface component or relationship that can be assessed using attributable Evidence. Evidence is the attributable material used to assess that signal for a defined target.
Signal ≠ Evidence. The signal is what is being assessed. Evidence is the support for that assessment. Keeping those concepts separate prevents a DNS record, configuration screenshot, policy, or attestation from being mistaken for posture by itself.
Evidence can be externally observed, internally observed, operational, or governance-based. The important questions are whether it is relevant, attributable, current enough, specific to the target, and sufficient to support the result.
Digital Trust Posture
Turn assessed Trust Signals into an evidence-backed posture view.
Digital Trust Posture is the condition implied by the evidence-backed assessment of Trust Signals across the scoped Trust Surface. It is not branding, a perception survey, or a universal single score.
A Trust Signal Scorecard gives the posture view structure. It records assessed condition, evidence coverage, strengths, weaknesses, unknowns, confidence, freshness, and priority gaps so that the result can support action and governance.
Unknown is useful. Missing or insufficient Evidence does not automatically prove a weak condition. It tells you that evidence acquisition or coverage must be resolved before a supportable judgement can be made.
The lifecycle
Discover → Assess → Harden → Govern → Signal.
Trust posture changes as domains, platforms, services, vendors, and ownership change. The lifecycle turns a point-in-time assessment into a repeatable operating rhythm.
Governance Integration cross-cuts this rhythm: the point is not simply to fix a condition once, but to keep posture owned, reviewable, and resilient to change.
Use it
Start with one bounded surface, not the whole organisation.
You do not need to “implement the framework” everywhere before it becomes useful. Choose one meaningful scope, work the lifecycle, and expand only when the operating rhythm is useful and supportable.
A practical first pass
- Choose a bounded surface. Email integrity, domains and DNS, a public digital service, or a critical vendor dependency are reasonable starting points.
- Name ownership and scope. Identify the systems, dependencies, targets, and people accountable for them.
- Select a small signal set. Assess only the Trust Signals material to the chosen surface.
- Gather attributable Evidence and create a scorecard. Record result, confidence, Evidence Freshness, limitations, and unknowns.
- Turn gaps into work and governance. Prioritise hardening, define change control, and set a review cadence so the posture does not quietly drift.
A useful first outcome: a bounded Trust Surface Inventory, an evidence-backed Trust Signal Scorecard, a prioritised hardening backlog, and enough ownership and cadence to repeat the assessment.
Continue from here
Choose the next depth you need.
You now have the conceptual path. Continue with an applied example, the task-oriented Apply hub, or the formal framework reference.