Worked walkthrough

From baseline review to governed practice

Follow one fictional Australian not-for-profit as uncertainty in the ten-question Baseline becomes evidence, governance interpretation, decisions, organisational records, accountable follow-up and recurring review.

This is a supporting example, not another assessment. It does not add a guide, score, benchmark, maturity model or assurance conclusion.

The organisation

About Southern Community Services

Southern Community Services is a fictional, medium-sized Australian not-for-profit headquartered in Melbourne. It provides community services across metropolitan Melbourne. Its website, staff email and fundraising campaigns are ordinary parts of service delivery and community engagement.

A small internal technology function works with Corporate Services, Fundraising, Communications and external suppliers. Domain responsibilities have accumulated across those relationships over time rather than being deliberately designed as one governance model.

The organisation is intentionally neither unusually mature nor unusually weak. Some important answers therefore exist in memory, supplier knowledge or assumptions rather than governed evidence. All domains below remain reserved example names.

How the organisation operates

The Head of Corporate Services is accountable for core organisational technology and the primary domain. The Technology Manager operates the registrar, DNS and Microsoft 365, while Fundraising and Communications retain relevant business ownership and external suppliers provide specialist delivery.

Recurring governance later sits in the existing Technology, Risk and Service Review rather than a new forum.

Domain portfolio

  • southerncommunity.example Primary public identity, website and staff email.
  • southernservices.example Defensive holding and redirect to the primary site.
  • winterappeal.example Previous fundraising campaign domain awaiting a retain/retire decision.
  • appeal.southerncommunity.example Current fundraising campaign and supporter-communication boundary.

Technology and suppliers

  • Melbourne IT - registrar
  • Cloudflare - authoritative DNS
  • Microsoft 365 - staff email
  • Fictional fundraising SaaS - supporter communications
  • Australian digital agency - website delivery and approved DNS changes

These are fictional scenario relationships, not endorsements or claims about what is representative of Australian NFPs.

Governance trigger

Why the review happened

A public website refresh and fundraising-platform change reached the existing technology and risk process. Questions about control, dependencies, sending authority and recovery could be answered only partly from memory, supplier knowledge and assumptions.

The organisation does not discover that its domain environment is bad.

It discovers that several important facts exist as assumptions rather than governed evidence.

Initial Baseline review

Ten unchanged questions, with evidence still to find

The team uses the canonical questions without turning the responses into a score, percentage, maturity level or assurance conclusion.

# Canonical question Response Reason
1 Which domains do we own, and why do we own them? Partial The primary and defensive domains are known, but the registrar export reveals winterappeal.example, and the campaign subdomain is inconsistently recorded.
2 Who is the accountable business owner for each domain? Partial The primary-domain owner is clear; campaign, defensive and legacy ownership is informal.
3 Who has registrar access, and how is that access controlled? Not sure Two internal administrators are expected, but historic digital-agency privilege cannot be confirmed in the meeting.
4 When do the domains renew, and who receives renewal notices? Partial Auto-renew is enabled, but notices and payment dependencies rely too heavily on individual mailboxes and knowledge.
5 Which providers host authoritative DNS? In place Cloudflare is known to host authoritative DNS and nameserver evidence agrees.
6 Which systems and suppliers rely on each domain? Partial Website and Microsoft 365 dependencies are known, but fundraising, redirects and supplier dependencies are not recorded together.
7 Which domains are authorised to send email? Not sure Microsoft 365 is approved, but fundraising and previous campaign sending paths need reconciliation.
8 Are SPF, DKIM and DMARC configured and reviewed? Partial Records exist, but expected state, review ownership and possible obsolete supplier authority are incompletely evidenced.
9 Are DNS changes logged, reviewed and recoverable? Partial Cloudflare has audit history, but agency changes do not consistently link approval, validation and rollback evidence.
10 What is the incident path if a domain, DNS record or email control fails? Not in place The general incident process exists, but domain-specific contacts, references, independent communications and recovery validation are not assembled into a usable path.
What the review revealed

The review does not produce ten remediation tasks.

The uncertainties cluster into the five existing practices. The guides provide a bounded route from questions to records and decisions rather than a new framework.

  1. 01
    Visibility, purpose, ownership and renewal

    Establish a domain register.

  2. 02
    Registrar/DNS authority and recoverability

    Control registrar and DNS authority.

  3. 03
    Approved email authority versus observable signals

    Govern email authority and public signals.

  4. 04
    Domain-layer response and recovery

    Establish domain incident readiness.

  5. 05
    Keeping evidence, decisions and exceptions current

    Run a recurring domain governance review.

Guide 01 walkthrough

Visibility, ownership, renewal and dependencies

Baseline signal
Questions 1, 2, 4 and 6 are Partial.
What they checked
Melbourne IT registrations, Cloudflare zones, Microsoft 365 verified domains, supplier records and campaign information.
What they found
winterappeal.example is registered but missing from the internal list. The campaign subdomain and supplier dependencies are not represented consistently. Renewal messages depend too heavily on individuals.
Governance interpretation
A registrar export proves a registration exists, not why it is held or who is accountable. Domain and subdomain dependencies need one governed organisational view.
Decision
Name owners and operators, move renewal notices towards a monitored role mailbox, and assign the Fundraising and Communications Managers a dated retain/retire decision for the legacy domain.
Record updated
The domain register now joins purpose, owner, operator, registrar, DNS, renewal, email use and material dependencies.
Remaining uncertainty
winterappeal.example remains registered while its explicit retain/retire decision is open. It is not automatically retired.
Guide 02 walkthrough

Registrar and DNS authority, access and recovery

Baseline signal
Question 3 is Not sure and question 9 is Partial.
What they checked
Named Melbourne IT and Cloudflare access, supplier roles, MFA, recovery contacts, secondary administration, transfer protection, audit history and change records.
What they found
Named internal administrators exist alongside an historic supplier path. The agency does not need registrar authority for normal website work. Supplier DNS work still needs a constrained zone role.
Governance interpretation
Operational convenience does not justify broad authority. Recovery must belong to the organisation and material DNS changes must be attributable, approved, validated and reversible.
Decision
Remove unnecessary registrar access, constrain necessary Cloudflare access, record organisational recovery paths and use the existing change process for material DNS work.
Record updated
The authority review records named access, MFA, protection, approved recovery-reference locations and audit evidence without copying credentials.
Remaining uncertainty
The documented provider-exit and recovery path still needs a future practical test.
Guide 03 walkthrough

Approved sender authority versus observable public evidence

Public observation tells the organisation what appears possible.
The authorised-sender record tells it what is approved.
Governance requires reconciling the two.

A passing public signal does not prove good governance. A missing signal does not prove negligence. Observation is not judgement.

Baseline signal
Question 7 is Not sure and question 8 is Partial.
What they checked
Approved business uses, Microsoft 365, the current fundraising platform, historical campaign configuration, SPF, DKIM, DMARC and relevant public evidence.
What they found
Microsoft 365 is the approved staff-mail sender. The fundraising platform is approved for supporter communication through appeal.southerncommunity.example. A previous campaign path remains visible or configured.
Governance interpretation
Public records show possible technical authority, but cannot establish internal approval or overall control effectiveness. The difference requires a decision.
Decision
Record the two approved paths and retain the previous supplier path only as a temporary exception with an owner, rationale and migration-point reconsideration.
Record updated
The authorised-sender register links purpose, owner, provider, visible and technical sending boundaries, evidence dates and exceptions.
Remaining uncertainty
One temporary fundraising/supplier sending exception remains until its defined migration point, when it must be removed or explicitly reconsidered.
Guide 04 walkthrough

A simple loss-of-authoritative-DNS tabletop

Assume at 9:15 am tomorrow the organisation loses access to authoritative DNS.

Baseline signal
Question 10 is Not in place, while authority and recoverability questions remain incomplete.
What they checked
The normal incident lead, service communications, DNS account reference, secondary administrator, provider escalation, known-good evidence, dependency order and independent communications.
What they found
The normal incident process is usable and the team can identify the Cloudflare account and secondary administrator. Provider escalation detail and service-validation sequencing are incomplete.
Governance interpretation
Having a general incident process is necessary but does not by itself make domain recovery executable. Evidence, authority, sequence and independent contact paths must join up.
Decision
Use the existing incident roles, add domain-specific provider references and validation order, and route open recovery work into the existing action system.
Record updated
The runbook records roles, dependencies, evidence locations, decision authority, recovery validation and follow-up without including credentials or sensitive recovery material.
Remaining uncertainty
The tabletop improves readiness, but one provider-exit or recovery capability still requires a controlled future test.
Guide 05 walkthrough

Keep the evidence and decisions current

Baseline signal
The initial review revealed records and decisions that could drift after the website and fundraising changes.
What they checked
The existing Technology, Risk and Service Review, its decision routes, and the domain register, authority review, sender register, renewal horizon, changes, incidents, observations and open actions available as a pre-read.
What they found
The existing quarterly forum can accommodate a focused 30-45 minute item. No new committee or separate workflow is needed.
Governance interpretation
A register is useful only while it remains true. Recurrence should review change, uncertainty, exceptions and decisions rather than reproduce every source record.
Decision
Add the item to the quarterly Technology, Risk and Service Review and route decisions and actions back into existing organisational systems.
Record updated
The agenda and action log capture decision owners, dates, destination records and completion evidence.
Remaining uncertainty
The three open items remain visible in the forum until decided, expired or tested; recurrence does not make them complete.
Closing state

What changed

The organisation can now demonstrate current organisational knowledge without claiming a perfect state.

Known and owned

Material domains, purposes, dependencies and accountable owners are recorded, with renewal responsibility moving towards an organisational mailbox.

Attributable and recoverable

Registrar and DNS authority, approved email authority, recovery roles and evidence locations are documented and traceable.

Kept in governance

Domain-layer evidence, exceptions and actions have a recurring place in an existing quarterly forum.

Accountable follow-up

What remains unresolved

The walkthrough does not end with ten In place answers. Material uncertainty stays explicit, owned and dated.

Legacy domain decision

winterappeal.example still requires an explicit retain/retire decision from the Fundraising and Communications Managers.

Temporary sending exception

One fundraising/supplier sending path remains temporarily approved until its migration-point expiry or reconsideration.

Recovery capability test

One provider-exit or recovery capability still requires a future controlled test.

Good governance is not achieving a score. It is knowing what is true, what remains uncertain, who owns it, what decision has been made and what happens next.

Try it with your organisation

Start with the questions, then use the bounded guides where uncertainty clusters

Your context will differ from this fictional example. Work through the Baseline privately, take away the review summary, and place evidence, decisions and actions into the organisational records and governance processes you already operate.