Pre-launch security checklist for non-technical founders

Set a proportionate go/no-go rule

Two people review a business planning report on a tablet at a table.

Pause launch if unresolved findings could let someone take over an account, expose customer information or disrupt an essential business service. Also pause if you do not understand an issue’s impact or how it will be addressed.

For lower-impact issues, decide whether the risk is acceptable in light of what the product does and the information it handles. Record who accepts each issue and the agreed follow-up. For a complex product or one handling sensitive information, consider independent security testing or specialist advice before deciding.

Use this checklist to ask for evidence

Two people stand together as one writes on a clipboard with a pen.

Use the checklist to request records or documented settings you can review, rather than a technical demonstration. Responsibility may sit with your developer, hosting provider, product supplier or your business. Mark each item ready, unresolved or agreed follow-up; completing the checklist does not certify security.

Check	Question to ask	Evidence to request	Responsible person	If missing or unsatisfactory
Accounts and access	Who owns key accounts, and who has administrator access?	Account and access list	Developer and business	Resolve unknown ownership or access before launch.
Data and test data	What information is collected, where is it stored, and is test data separate?	Data flow and storage notes; test-data settings	Developer or product supplier	Pause if data exposure or handling is unclear.
Production and deployment	Are production settings separate from testing, and how are changes released?	Documented settings and deployment process	Developer or hosting provider	Resolve unsafe or undocumented production access first.
Dependencies and external services	Which components and services does the product rely on?	Inventory and service account ownership	Developer or product supplier	Investigate unknown or unowned critical services.
Backups	Are essential data and files backed up, and can they be restored?	Backup settings and restore records	Hosting provider or developer	Pause if essential information cannot be recovered.
Monitoring and incidents	Who receives alerts and who should be contacted about an incident?	Alert arrangements and contact procedure	Hosting provider, developer and business	Agree named contacts and follow-up before launch.

Accounts, ownership and access

Two people review paperwork on a desk beside a laptop and glasses.

Before launch, make sure the business can identify who controls its key accounts and who can reach the live system. Ask the developer or hosting provider to show the current arrangements rather than relying on verbal assurance; the business should know how to retain or recover access if a supplier relationship ends.

Check	Question to ask	Evidence to request	Responsible person	Decision if missing or unsatisfactory
Business ownership and recovery	Who controls the domain, hosting, application, source code and essential third-party accounts? How can the business retain or recover access if the supplier relationship ends?	A written account and ownership list, plus a documented route for the business to regain access.	The founder or business account owner, with the developer or hosting provider confirming the arrangements.	Pause launch if ownership is unclear or the business cannot recover access. Resolve this before release.
Access to live systems	Who can access production systems, and does each person need their current level of access?	A dated access list showing each person, the systems they can reach and their access level.	The person responsible for administering the live environment.	Pause if access cannot be accounted for or is broader than the business has agreed. Record and resolve the gap before launch.
Important account protection	Is multi-factor authentication available and used for important accounts? If not, what alternative protection is in place?	Confirmation of the settings for key accounts, or a written explanation of the alternative and any remaining concern.	The account owner or administrator, with the supplier confirming relevant settings.	Do not assume every service works in the same way. Escalate missing protection for important accounts and agree whether it must be fixed before launch.
Unused accounts and changes	Have accounts that are no longer needed been removed, and who will make future access changes?	Written confirmation that unused accounts have been removed and the name of the person responsible for adding, changing and removing access.	The named access administrator.	Pause if former or unidentified users may still have live access. If a lower-priority gap remains, name an owner and agree a follow-up before proceeding.

Data collection, storage and test data

Hands point at a tablet displaying a simple diagram beside a cup of coffee.

Map the information before approving launch. Ask the person who built the product to show what it collects, where it goes, who can see it and whether live customer information appears anywhere outside the live system.

Information collected. Ask: “What information does each form, account or product feature collect, and why is it needed?” Request a list of fields and a simple data-flow description, including information sent to suppliers or external services. The product owner should confirm the list. If the team cannot account for sensitive or personal information being collected, pause launch until its purpose and handling are understood.
Storage, sharing and access. Ask: “Where is this information stored, which services receive it, and who can access it?” Request a simple diagram or written map showing the route from collection to storage and onward sharing, plus the names or roles responsible for access settings. The developer or hosting provider should explain the technical route; your business should confirm who needs access. Unknown destinations or access that cannot be explained should be resolved before launch.
Test and live data. Ask: “Are test and live systems separate, and has real customer information been copied into testing?” Request confirmation from the developer and, if available, a demonstration of which environment is being used. If real information is used for testing, ask why, who can see it and how it is removed or protected. Do not approve launch while the team cannot account for customer information in test systems.
Ownership of settings. Ask who is responsible for the product’s data settings, supplier connections and access list after launch. Request named owners and confirmation that the relevant settings have been checked. A missing owner is a launch blocker if it leaves information exposed or unaccounted for; otherwise, record the gap with an agreed owner and follow-up.

Where personal data is involved, ICO guidance says organisations must use appropriate technical and organisational measures to implement data-protection principles and safeguard people’s rights, with data protection considered from design through the processing lifecycle. ^{1, 2} If you are unsure whether a duty applies to your situation, check with the ICO or an appropriate adviser rather than guessing.

Production settings, deployment and updates

Two people look at a whiteboard covered with sketches and screen mock-ups.

Ask the developer or hosting provider to show how the live service is configured, how changes reach it and who keeps it maintained. NCSC guidance says security should be considered from the start of designing and developing an online service and built into its delivery, management and maintenance. ^{3, 4}

Production settings and ownership: Who can change settings on the live service, and who approves those changes? Request the names or roles responsible and a short description of the approval process. If nobody clearly owns production changes, agree an owner and process before launch; pause until then.
Live and test environments: How is the live service kept separate from development or testing, and what checks happen before a change is released? Ask for a plain-English description of the separation and the release checks, including who confirms a change is ready. If the team cannot explain how a test change is kept from affecting the live service, get that clarified before launch.
Release and recovery: Who carries out a deployment, and what happens if a change causes a problem? Request the release steps and the agreed response for reversing or correcting a faulty change. If there is no practical way to manage a failed release, resolve that gap before launch.
Updates and maintenance: Who checks for and applies updates to the software and its hosting environment, and how will your business know when action is needed? Ask for the responsible person or provider, how updates are assessed and applied, and how you will be told about work or issues that affect the service. If ownership is unclear, name an owner and agree a workable process before launch.

Record each answer, the evidence you have seen and any follow-up owner. An agreed process with a named owner can address routine maintenance work; an unknown owner or an unexplained gap in how the live service is changed should hold up approval.

Dependencies and third-party services

Yellow fibre-optic cables connect to ports on a network panel.

Ask the developer to identify the software components and external services the product depends on. The aim is to know who notices a change, who decides what to do, and how the business will hear about an issue—not to assume a particular tool or supplier arrangement.

Check	Question to ask	Evidence to request	Responsible person	If missing or unsatisfactory
Dependency list	Which components and external services are important to the live product?	A current list stating what each service or component does and how the product relies on it.	Developer or technical lead to prepare it; founder to confirm business contacts.	Pause if a critical reliance is unclear and its effect on the service cannot be assessed.
Updates	How are updates to software components identified, assessed and applied?	A description of the update process, including who reviews changes and records completion.	Named technical owner.	If there is no process or owner, agree one before launch for important dependencies.
Supplier changes	Who monitors supplier notices that could affect the live product, and how will the business be told?	The agreed contact route and the person responsible for reviewing notices and escalating relevant changes.	Supplier contact and named person within the business.	Agree an owner and notification route before launch where a supplier change could disrupt an important function.
Unowned dependencies	Is any important component or service missing an update or monitoring owner?	A list of gaps, with the proposed interim action and a named person to follow it up.	Founder to ensure the gap has an owner; technical lead to explain the risk.	Do not leave the gap implicit: resolve it before launch or document an agreed plan and review point.

Know which findings should pause launch

A suited presenter points towards a whiteboard as colleagues sit around a meeting table.

Pause launch when a serious security risk remains unresolved, or when the business cannot show who controls essential systems and how to respond if something goes wrong. If a gap is understood and does not leave a serious risk unmanaged, record a named owner, a specific action and an agreed follow-up before deciding whether to proceed.

Finding	Launch decision	What to establish or record
No clear control of an essential account, or no workable way to recover access.	Pause.	Ask who owns the account, who can access it and how access would be recovered. Do not proceed until the business can establish control.
A serious risk to customer or business data is unresolved, or sensitive data flows and access cannot be explained.	Pause.	Ask the supplier to explain the risk, which information is affected, where it goes and who can access it. Seek specialist advice if its seriousness is unclear.
An essential part of the service has no accountable owner, or there is no workable route for reporting a suspected incident.	Pause.	Name the person responsible for the service component and agree how staff will report a concern and who will receive it.
Recovery is essential to operations, but nobody responsible can explain how data or access to the service would be restored.	Pause.	Ask the responsible person to explain the recovery steps and what they would restore. Resolve uncertainty before relying on the service.
A gap is understood, does not present a serious unresolved risk and can be managed after release.	Proceed only with an agreed follow-up.	Record the issue, its named owner, the action, the agreed follow-up and how completion will be tracked.

Do not treat an unanswered question as proof that a system is unsafe, but do not approve launch on an assumption either. Ask the developer or hosting provider for an explanation and relevant evidence. If neither you nor the supplier can confidently assess the nature or seriousness of a finding, get independent testing or specialist advice before making the release decision.

Agree who is responsible after launch

Colleagues sit around a table with folders, papers, a tablet and cups of coffee.

Before launch, make sure every recurring security task has a named owner, a clear route for getting help and a way to confirm that agreed work has been completed. Put this handover somewhere the relevant business contacts can find it, rather than leaving it in an email thread or relying on one person’s memory.

Accounts and access: Record who approves new accounts and access changes, and who removes access when a staff member or supplier no longer needs it. Ask who will review access and how changes are recorded.
Production settings and releases: Name the person responsible for approving changes to the live service and coordinating releases. Confirm how they will tell you a change is ready and where release records are kept.
Updates and dependencies: Assign someone to review and arrange updates to the product and its important components or third-party services. Ask what update evidence or status report you will receive, and who decides what to do if an update cannot be applied.
Backups and recovery: Record who checks that backups are being made and who coordinates recovery if the service or its data becomes unavailable. Ask what evidence will show that the agreed backup and recovery tasks have been completed.
Monitoring and incidents: Identify who reviews alerts, who is contacted if something appears wrong, and who coordinates the response on your side. Keep the supplier’s support route and escalation contacts with your own internal contacts, so the right people can be reached when needed.
Open issues: Carry forward every unresolved item with a named owner, the agreed next action and a point at which it will be reviewed. Ask what confirmation or evidence will close it; launch approval should not make the issue disappear.

NCSC guidance supports treating security as part of designing and developing an online service, and continuing through delivery, management and maintenance. ^{3, 4} Launch is therefore a handover point, not the end of the work: agree who will keep each task moving and how you will know it has been done.

Check whether a maintained platform would meet the need

An overhead view of a desk with laptops, documents, a phone and other technology during a meeting.

A custom build is not always the right answer. If your business needs a standard website or a familiar function such as booking, selling online or managing enquiries, compare established platforms before commissioning bespoke software. Compare any platform's stated capabilities with the way your team actually works before deciding whether it is suitable.

Compare the operational responsibilities as well as the features. Ask who will apply updates, arrange backups, monitor the service, provide support and control the accounts. Confirm that your business can retain access and recover its data if a supplier relationship changes. Choosing a platform does not remove these questions; unclear ownership can leave the same gaps you were checking for before launch.

Custom software may be justified when your workflows or required integrations do not fit available packages, or when adapting your process would create a material problem. Set out what the package cannot do, what workarounds would involve and who would maintain a custom system before deciding. If a maintained platform meets the need, there may be no reason to commission a bespoke product.

For sites and systems built or taken over by DevAgency, agree who will handle hosting, updates, backups, monitoring and support. Set out these arrangements before work begins or changes hands. The checklist remains useful whether or not you contact DevAgency.

Photographs are illustrative stock images, not DevAgency staff, clients or products.

A Pre-Launch Security Checklist for Non-Technical Founders

Set a proportionate go/no-go rule