Webscan Documentation

Lesson 21 · Team, roles & governance

Phase 5 · Delivery & governance — Lesson 21 of 21 · All lessons

Objective: run webscan as a team responsibly — manage members and roles, control your organisation's settings and seats, and understand the irreversible actions. Plus a look back at everything you've learned.

Before you start: you'll want to be an Owner or Administrator of an organisation (Lesson 2) to try the actions here.

What "governance" means

Governance — the controls that decide who can do what in your organisation, and how the account itself is managed. It's the difference between a tool one person uses and a platform a team runs safely: the right people have the right access, and the risky account-level actions are protected.

You met the pieces in Lesson 2; this lesson is about using them deliberately.

Roles, revisited

Access is controlled by each member's role. As a reminder:

The principle to apply: least privilege — give each person the least access they need to do their job. A stakeholder who just wants to see progress is a Viewer, not an Administrator. This limits both mistakes and risk.

Managing members

From the Team page (Owners/Administrators only):

• Invite a member by email with a chosen role — they accept via an emailed link (Lesson 2). Note you can't invite someone straight to Owner; ownership is handled deliberately, not handed out in an invite.
• Revoke a pending invitation that hasn't been accepted yet.
• Remove an existing member when they no longer need access.

Seats are a plan limit. The number of members (plus pending invitations) is capped by your plan (Lesson 2). If invites are blocked, you're at the seat limit — remove someone unused or upgrade on the Billing page. That connection between governance and billing is deliberate: access has a cost.

Organisation settings

On the Organisation settings page (Owners/Administrators) you can rename the organisation and Save changes. From here you also reach the account-level actions — including the one to handle with care.

Deleting an organisation

Delete this organisation is Owner-only and irreversible. Deleting an organisation removes everything inside it — projects, websites, scans, findings, issues, reports, the lot. There is no undo.

Treat this like any destructive action: be certain, and prefer removing individual projects or websites if that's really what you mean. (This is the same "irreversible actions need deliberate human intent" philosophy you saw for production safety in Lesson 20 — here it applies to your own account.)

Other governance touchpoints

Two settings covered elsewhere also belong to governance, both Owner/Administrator controls:

• Report branding (Lesson 19) — your organisation's identity on delivered reports.
• Sandbox build verification (Tier B) (Lesson 20) — the opt-in for deeper fix verification.

Tips & pitfalls

• Apply least privilege. Most people should be Auditor, Developer, or Viewer; keep Owners and Administrators few.
• Keep at least two people with elevated access so you're never locked out if one leaves — but no more than you need.
• Off-board promptly. Remove members who leave; revoke stale invitations. It keeps your seat count honest and your access list trustworthy.
• Pause before deleting an organisation. It's the one truly irreversible action in the product — export any reports you need first.

Recap

• Governance is who-can-do-what plus account-level control; apply least privilege.
• Owners/Administrators manage the Team (invite / revoke / remove); seats are capped by your plan.
• Organisation settings cover renaming and the Owner-only, irreversible delete.
• Report branding and Tier B opt-in are governance settings too.

You've completed the path 🎉

That's the whole curriculum. Look at what you can now do end-to-end:

• Foundations — set up your workspace, scan a site, and read every finding.
• Triage & fixing — verdicts, issues, AI assistance, source-code fixes via pull request, and retests.
• Beyond the public page — authenticated scans, agentic exploration, journeys, and manual audits.
• At scale — recorded sessions, custom rules, prioritisation and the verdict model, and monitoring.
• Delivery & governance — reports and branding, production safety, and running a team.

A complete audit now looks like this: scan (and authenticate, explore, journey, and manually audit as needed) → record verdicts → open issues → fix (with assistance and pull requests) → retest → monitor for regressions → deliver a branded report. Every feature you learned is one step on that line.

For quick day-to-day reference, keep the User Guide handy — it's the searchable companion to these lessons. And remember webscan's own motto: accessibility is a practice, not a score. These lessons taught you the tools; the practice is now yours to run.

Previous: ← Lesson 20 · Environments, blast radius & production safety Back to: All lessons