A useful brief
Connect buyer needs to agreed requirements.

ISO 9001:2026 / IMPLEMENTED IN PROJECT WORKFLOW
The finish matters. So does everything that gets you there: the right brief, an owned decision, a careful check and a result worth keeping.
Open the working handbookHOW THE PROJECT MOVES
Connect buyer needs to agreed requirements.
Name owners, resources and acceptance criteria.
Build from approved inputs and reviewed changes.
Verify the result and record client acceptance.
Transfer approved versions, care and operating knowledge.
THE IMPLEMENTATION BOUNDARY
The quality workflow begins with agreed buyer needs and follows them through creation, checking and handover. Your engagement records the services, delivery owners and acceptance evidence that belong to that scope. The procedures here explain our project practice rather than reproduce the standard’s wording.
This handbook follows ISO 9001:2026, published on 16 September 2026. Its clause map connects the current edition to the project workflow, including quality culture, ethical behaviour and separate actions for risks and opportunities.
Standard edition and background: ISO’s official standard page .

Management-system certification concerns the activities stated in its scope. The supplied quality reference accompanies a workflow of planned delivery, accountable approvals and continued improvement. Confirm the certificate’s applicable edition and coverage for your engagement; its reference alone does not certify an individual website.
FROM REQUIREMENT TO PRACTICE
The quality chapters follow an agreed requirement through an owned action and the record used to check its result. Read along the delivery sequence, or open the clause that helps you examine a particular approval, handover or improvement.
CLAUSE 4 / THE PROJECT HANDBOOK
A brief belongs to a business, its buyers and the people who will use the result.
The project lead records the organisation’s purpose, market, delivery constraints and existing systems before proposing a build. Climate-related disruption and buyer expectations are considered for relevance, including hosting resilience and physical production.
Research identifies customers, end users, staff, suppliers and any public-service stakeholders who affect the outcome. Relevant needs and requirements are recorded, including climate expectations, and the project states which are addressed through its quality system. Applicable legal and contractual duties remain part of the agreed requirements.
The agreed scope names the website, software, integrations, connected print and ongoing care included in this engagement. Any non-applicable quality requirement is justified without weakening delivery or customer obligations.
Discovery, content, design, development, verification, release and care operate as connected processes. Each has defined inputs, outputs, ownership, resources, acceptance rules and performance checks. Current working instructions support delivery; approvals, test results and release records demonstrate that the process happened as planned.
CLAUSE 5 / THE PROJECT HANDBOOK
Creative freedom works best when somebody can say yes, stop, correct and explain.
Leadership makes quality and ethical behaviour part of daily decisions: accurate claims, honest approval records and the freedom to raise a concern. The accountable lead provides capacity, reviews performance and resolves conflicts between quality, cost and timing. A failed gate receives action instead of an undocumented override.
The team translates the client’s service promise and buyer research into acceptance criteria. Contractual and applicable statutory requirements are reviewed; satisfaction is revisited at handover and during agreed care.
The quality policy connects the organisation’s context and direction to useful client outcomes, applicable requirements and continuing improvement. It provides a basis for objectives and becomes a controlled, shared working promise. Contributors discuss its relevance to their task, and appropriate interested parties can access the current commitments.
The responsibility map separates the client’s business-fact approval, the maker’s work, the reviewer’s checks and release authority. Deputies are identified so a missing person cannot turn an urgent launch into an unapproved change.
CLAUSE 6 / THE PROJECT HANDBOOK
A better project prepares for difficulty and creates space for opportunity.
Context, stakeholder requirements and process behaviour inform the risks and opportunities that could affect quality-system results. The team considers dependable delivery, conforming outputs and customer satisfaction. Potential harm and potential benefit are identified distinctly so a promising improvement does not disappear inside a defects list.
Risk owners analyse likely consequences and exposure, decide priorities and plan responses proportionate to the effect on intended results. Controls become delivery tasks with owners and review points. Checks examine whether the response worked, including whether approved information and service operation remain dependable during disruption and recovery.
The team analyses potential benefit, feasibility and fit before choosing an opportunity. A simpler approval route, reusable content or more accessible journey receives a planned action, owner and measure. The action is integrated into delivery, implemented and evaluated for actual benefit to conformity and customer satisfaction.
Objectives fit the policy, applicable requirements and the result the client needs. Appropriate measures, targets, owners, resources, timing and evaluation methods are agreed, communicated and reviewed. A booking objective might pair a tested availability rule with an end-to-end acceptance exercise; commercial improvements are measured rather than promised without evidence.
Before a quality-system change, the team reviews its purpose, consequences, dependencies, resources and responsibilities. The plan defines implementation, communication, required competence and the checks that will evaluate the change. Client approval covers scope effects; after implementation, results are reviewed and unresolved impacts receive owned action.
CLAUSE 7 / THE PROJECT HANDBOOK
People, tools, knowledge and trustworthy records make the ambition deliverable.
Planning identifies the people, environments, software and external services required for the agreed result. Available internal capability is compared with gaps; specialist support is commissioned only within the authorised scope.
Research, writing, design, engineering and review tasks go to people with suitable capability and capacity. Contributed hours follow the same role requirements as paid work; volunteering does not waive delivery checks.
The build, preview, production and recovery environments have explicit purposes. The published service and its runtime dependencies remain on the commissioned production provider, so the local build server can be offline without taking the website down.
The working environment supports focused delivery, respectful challenge, accessible communication and realistic review time. Contributors can question an unsupported claim or unsafe shortcut without losing the review route. Physical, social and organisational conditions are considered where they affect process operation and the quality of the result.
Browser tests, accessibility tools, performance measurements and acceptance exercises are chosen for their purpose. Versions and conditions are recorded so results can be interpreted and repeated instead of treating one automated score as proof of everything.
Where print colour, physical dimensions or another contractual measurement needs traceability, suitable verified or calibrated equipment and records are required. Ordinary software checks use validated methods; equipment traceability is assessed for relevance, not assumed for every task.
The team records architecture decisions, operating instructions and lessons that another authorised contributor needs. Handover covers configuration, ownership and known limitations; new knowledge is added when changes expose a gap.
Required skills are identified before allocation. Experience, work review or appropriate training demonstrates capability; where a gap is found, supervised work and a later effectiveness check replace an unsupported assumption.
Contributors understand the policy, relevant objectives, their contribution and the consequences of missed requirements. Awareness includes quality culture and ethical behaviour: verify a business claim, record approval honestly, disclose uncertainty and raise an issue before publication. Briefings connect those expectations to the actual task.
The communication plan names what is shared, with whom, when and through which approved channel. Decisions are recorded after meetings; urgent issues reach a named owner rather than becoming scattered messages.
The project pack contains the scope, requirements, approved content, reviews, tests and release evidence needed to operate and assess the process. Its depth follows the project’s complexity and risk rather than a fixed pile of paperwork.
Records carry a title, owner, date and version suitable for their format. New or revised material is checked and approved before it becomes the authorised source for building, publishing or reusing in print.
Current records are available and usable for authorised people while confidentiality and integrity remain protected. Distribution, retrieval, changes, retention and disposal have owners; external sources are identified and obsolete versions are withdrawn from use. Retained evidence stays protected from unintended alteration, loss or inappropriate disclosure.
CLAUSE 8 / THE PROJECT HANDBOOK
The largest chapter follows the idea through making, checking and releasing.
Requirements, resources, acceptance criteria and records are agreed before production. Planned changes are controlled; unintended changes are assessed. Outsourced work remains inside the project’s checks rather than being treated as somebody else’s problem.
The client receives a clear route for questions, feedback, complaints, changes and approval. Information about services, project progress and client-provided material is communicated through the agreed channels, including any contingency arrangements.
Discovery captures explicit requests, necessary unstated operating needs and applicable obligations. The team tests whether it can deliver the proposed claims before a website description, integration or service promise enters the scope.
The lead checks deliverables, intended use, timing, dependencies and applicable requirements before an engagement or changed order is accepted. Differences are resolved with the client and verbal instructions are confirmed. Review outcomes and newly identified requirements remain available as evidence beside the authorised scope.
When a requirement changes, the affected brief, content, design, tests and handover are updated together. Relevant contributors are informed so a fresh instruction does not coexist with an older acceptance criterion.
New websites and software use a defined design and development process, proportionate to complexity. A buyer need moves through research, concepts, prototypes and implementation with review points before it becomes a live service.
The plan considers stages, responsibilities, review, verification, validation, client involvement and specialist interfaces. The expected lifespan, support needs and evidence required shape the depth of prototype and testing work.
The team gathers functional needs, buyer evidence, previous lessons, legal or contractual constraints and likely consequences of failure. Ambiguous or conflicting inputs are resolved before they are translated into interface or system behaviour.
Reviews ask whether the approach is sound; verification checks outputs against inputs; validation checks whether the intended users can achieve the agreed purpose. Issues, resulting actions and approval evidence are retained at each appropriate stage.
Approved layouts, content, specifications and acceptance criteria contain enough information for implementation and operation. Important characteristics, dependencies and safe-use instructions accompany the result instead of remaining in the designer’s head.
A changed layout, data model or workflow is reviewed for effects on existing work and delivered services. The change, authorisation, checks and any action needed to prevent harm are recorded before it is released.
Hosting, media, software, print and specialist providers are evaluated against capability, reliability and agreed obligations. Selection, monitoring and later re-evaluation are recorded, including actions when performance falls short.
The team considers how an external service could affect the final result and checks whether the provider’s controls are sufficient. Acceptance, monitoring and fallback depth follow the dependency’s impact, with overall delivery accountability retained.
Orders and briefs state required outputs, approval conditions, competence, interaction and verification expectations. Requirements are checked for completeness before being passed on, including any client or team review needed before acceptance.
Makers work from approved inputs using suitable tools, competent people and defined checks. Release conditions, error prevention and post-delivery arrangements are established; a process that cannot be fully checked later receives appropriate validation before use.
Content revisions, build versions and releases have clear identifiers and approval states. Traceability links the delivered version to requirements, tests and authorisation so the team can investigate or restore the right result.
Client files, credentials, branding and intellectual property are identified and protected while in the team’s care. Loss, damage or unsuitable material is reported to the owner and recorded rather than quietly replaced or reused elsewhere.
Content, files and production artefacts remain intact during storage, transfer and handover. Controlled locations, checksums where useful and appropriate packaging help prevent a corrupted upload or incorrect version reaching the client.
The scope sets support responsibilities, maintenance, retention and any warranty or contractual duties. Care decisions consider likely problems, service lifespan, client feedback and applicable obligations; ongoing work is agreed rather than implied.
A production or service change is reviewed for continuing conformity before use. The authorising person, review findings and necessary actions are recorded, with proportionate checks of affected journeys and dependencies.
The client’s content and acceptance approvals meet the technical release checks before publication. Evidence identifies the accepted version and authorising person; an exception requires explicit authorised agreement and a recorded decision.
A result that misses requirements is identified and controlled to prevent unintended use or delivery. The team corrects, withdraws, suspends or obtains an authorised concession as appropriate, communicates with the client when needed and verifies corrected work. The record identifies the failure, action, concession and deciding authority.
CLAUSE 9 / THE PROJECT HANDBOOK
Evidence gives the project a way to learn beyond opinion or a polished launch.
The project agrees what is monitored, how and when, and who reviews it. Delivery checks and service measures are retained with their conditions; analytics are used only where commissioned and configured appropriately.
Feedback is gathered at review, handover and agreed follow-up points. Complaints, repeated questions and direct conversations are considered alongside any survey so satisfaction is not reduced to a single score.
Evaluated results inform conformity, satisfaction, process effectiveness, supplier performance and improvement. The effectiveness of risk responses and opportunity actions is considered separately. Repeated delays or failed journeys become owned corrective work, while a successful trial can become an approved new way of operating.
Internal audit examines whether the defined quality arrangements meet relevant requirements and operate effectively. A completed release checklist alone does not establish that earlier approvals, supplier checks or corrective actions worked.
The audit programme reflects process importance, changes and previous findings. Each audit has objectives, scope, criteria and timing; reviewers preserve impartiality and findings reach relevant management. Corrections and corrective actions are followed through, with evidence of the programme, results and closure retained.
At planned intervals, leadership reviews whether the quality system remains suitable, adequately resourced and effective. Project delivery evidence is brought together with the programme’s priorities instead of treating review as a ceremonial sign-off.
Leadership considers previous actions, context changes and changes in relevant stakeholders’ needs, alongside customer feedback, objectives, conformity, process results, audits, suppliers and resources. The review evaluates risk responses and opportunity actions separately, then examines improvement options with enough evidence to decide priorities.
Review outputs identify improvements, needed system changes and resource decisions. Each action receives an accountable owner and follow-up date, allowing the next review to judge whether the promised change took place.
CLAUSE 10 / THE PROJECT HANDBOOK
An issue becomes useful when the system changes and the change is checked.
Monitoring, measurement, analysis and management review identify opportunities that lead to action. The team improves processes, outputs and services, prepares for future client needs and corrects, prevents or reduces unwanted effects. Approved lessons update tests, handovers and working arrangements, with later checks of whether the changes improved the system.
A nonconformity is contained and its consequences addressed. The team reviews what happened, investigates causes and similar exposure, applies proportionate corrective action and evaluates its effectiveness. Risk or system information is updated where needed. The nature of the failure, actions and outcomes remain available as evidence for accountable closure.
QUALITY CULTURE / THE CURRENT EDITION
The 2026 approach makes room for honest challenge, careful claims and decisions that serve the client’s real purpose. Leadership supports that culture; every contributor knows how their work, judgement and conduct affect the result.
Risks and opportunities have distinct actions and evaluations. Changes are planned, communicated and checked after implementation. Evidence from delivery and management review feeds improvement, helping useful lessons become part of the next project.
Current edition and principles: ISO’s 2026 edition explanation . Clause structure: the published national adoption . Annex A supplies interpretation guidance; it adds no separate requirements.
CARE YOU CAN FOLLOW
Describe the result your buyers should be able to achieve. Together we can define the requirements, responsible contributors and acceptance record that will turn that ambition into checked, usable work.