10 September 202610 min read

Founders: 12-Point Web App Security Checklist, Exact Proof to Request

Engineer reviewing web security activity evidence

Require and verify eight checks before you sign off on a hired web app: multi-factor authentication, TLS everywhere, encrypted backups with a tested restore, centralized logging, a documented patch schedule, a signed data processing agreement with named subprocessors, and a written incident response plan. Ask the vendor for a documented checklist or acceptance sign-off tied to each item, plus a prioritized remediation plan for anything that fails. Use the breakdown below as your acceptance test or RFP attachment, item by item.

TL;DR:

Vendors must demonstrate proof of multi-factor authentication, TLS encryption, and encrypted backups before the app goes live, with confirmatory screenshots or reports.

A documented patch schedule, separate staging environment, signed data processing agreement, and incident response plan are essential prerequisites for launch approval.

Regular verification of access controls, including role matrices and session security, must be maintained through logs and periodic reviews, ideally from an incognito session.

Continuous security practices like weekly patch checks, quarterly health reviews, and annual vulnerability scans are necessary to mitigate evolving risks post-launch.

Ampersand Labs can provide ongoing security assessments, incorporating this checklist into development and support engagements for existing or upcoming projects.

What Should Be on Your Web App Security Checklist?

You don’t need to read code to run this checklist. You need to know what to ask for and what counts as proof. Each item below names the vendor deliverable and how you verify it, plus whether it’s a go-live blocker or something you schedule for the first 30 to 90 days.

Multi-factor authentication on all admin accounts. Ask for a screenshot of MFA enforcement settings. Must-have before go-live.
TLS encryption in transit. Ask for the SSL certificate details or a scan report. Must-have before go-live.
Encryption at rest for sensitive fields. Ask which database fields are encrypted and how. Must-have before go-live.
Documented backup schedule with a completed restore test. Ask for the last restore test date and result. Must-have before go-live.
Centralized logging for admin and data actions. Ask for a sample export covering one week. Schedule for 30 days.
Written patch and dependency update cadence. Ask for the last dependency scan report. Schedule for 30 days.
Staging environment separate from production. Ask for the release process document. Must-have before go-live.
Rollback plan for failed deploys. Ask for the last rollback log or a dry-run summary. Schedule for 30 days.
Signed DPA naming subprocessors and data locations. Ask for the signed document. Must-have before go-live.
Incident response plan with named contacts. Ask for the runbook and escalation contacts. Must-have before go-live.
Monitoring and alerting for unusual activity. Ask for a sample alert or dashboard screenshot. Schedule for 90 days.
Role matrix showing who has admin access. Ask for the current list and last review date. Schedule for 30 days.

Any vendor that hesitates on items 1, 2, 4, 7, 9, or 10 isn’t ready for go-live, regardless of how polished the demo looks.

Authentication and Access Control: What to Demand

Weak access control is the fastest way an agency-built app gets compromised, usually through a shared admin password nobody rotated since launch. Your job isn’t to configure this yourself. It’s to demand proof it’s configured correctly.

Require MFA on every admin account, plus just-in-time elevation so nobody sits logged in with full privileges by default.
Ask for a role matrix listing every admin account and who owns it, with a commitment to review privileges monthly.
Request configuration notes or screenshots showing session timeouts, secure cookie flags, and the password policy in place.
Log in with a low-privilege test account and confirm you actually can’t reach admin pages or export data you shouldn’t see.

Pro Tip: Run your access checks from an incognito or clean browser session, never your developer’s logged-in laptop. A session cluttered with old admin cookies or cached permissions will mask exactly the gaps you’re trying to find.

Ask for logs showing that access restrictions were enforced during a recent week, not just a policy document describing what should happen.

Data Protection: Encryption, Location, and Logging

Data protection is where nontechnical buyers get talked past most easily, because “we use encryption” sounds reassuring whether or not it’s true for the fields that matter.

Require TLS across the entire application, not just the login page, and ask for a certificate report proving it.
Require encryption at rest for sensitive fields (payment data, personal identifiers, health information) and ask which specific columns are covered.
Ask where processing actually happens and get a list of subprocessors and data locations written into the DPA itself.
Demand logging and traceability for who accessed or changed sensitive data, plus documented retention and erasure procedures.

If your app handles large volumes of sensitive data or does anything resembling automated profiling, you should require a data protection impact assessment before launch. Swiss data protection practice expects this kind of documentation and traceability for high-risk processing, and cloud due diligence guidance recommends the same scrutiny of subprocessors before you sign anything, per Chambers and Partners’ cloud computing practice guide.

Secure Build and Deployment Controls to Require

How code gets from a developer’s laptop to your live site determines whether a bad update takes down your app for an hour or for a week. This is a process question, not a technical one, and you can hold a vendor to it without reading a line of code.

Require a documented release process with separate staging and production environments, a written rollback plan, and an agreed deploy calendar.
Ask who holds production secrets and keys, and push for the smallest possible number of people with direct access.
Request evidence of automated testing (CI proof) and deployment logs showing what shipped and when.
Require scheduled backups with a documented, dated restore test, not just a backup job that runs and is assumed to work.

A backup nobody has restored is a hope, not a safeguard. Ask for the date of the last successful restore test before you sign off on go-live.

Dependencies and Patching: Keeping Third-Party Risk in Check

Most web apps run on dozens of third-party libraries the vendor didn’t write and may not be watching closely. That’s where a huge share of real-world breaches originate, quietly, through a component nobody remembered to update.

Require a dependency inventory and a named person or role responsible for patching cadence.
Ask for a written policy on end-of-life components and how fast the vendor responds to a newly disclosed critical vulnerability (CVE).
Verify with a recent dependency scan report or a clear vendor statement on how often updates run.

A vendor with no answer to “how fast do you patch a critical CVE” is telling you patching happens reactively, if at all.

Monitoring, Logging, and Incident Response: What Evidence to Ask For

Every app gets probed, scanned, or hit with credential-stuffing attempts eventually. What separates a manageable incident from a disaster is whether anyone notices in time and whether the response is rehearsed rather than improvised.

Require operational logging and alerting, plus a written incident response plan with named, reachable contacts.
Ask for evidence the plan has actually been tested, whether through a tabletop exercise or a real incident handled in the past year.
Insist on a first-response timeframe in writing, such as triage beginning within 24 hours of detection.
Require contractual commitments (SLAs) covering incident notification speed and remediation support.
Verify by requesting runbooks, a redacted incident summary, or a vendor’s own incident report from a past engagement.

Pro Tip: Ask specifically for a redacted incident summary, not a clean bill of health. A vendor who has never had a single security event in years running production apps is either extremely lucky or not looking closely enough.

Switzerland’s National Cyber Security Centre publishes ICT minimum standards that explicitly call for monitoring and incident readiness, a useful reference point if a vendor pushes back on these requests as excessive.

Vendor Due Diligence: The Contract Checklist

The contract is where security promises either become enforceable or evaporate the first time something goes wrong. This matters just as much for a banking web app handling regulated financial data as it does for a simple marketing site collecting emails.

Require a DPA that names every subprocessor, states where data physically lives, and spells out cooperation duties if a breach happens.
Ask for certifications or third-party audit reports where relevant, such as ISO/IEC 27001 or ISAE 3402, especially for vendors touching financial or health data.
Negotiate the right to audit or to receive regular third-party reports, and insist any finding comes with a prioritized remediation plan with actual timelines attached, not just a promise to “look into it.”

A vendor that resists a right-to-audit clause is telling you something about how confident they are in their own controls.

How Often Should You Verify Security After Launch?

Security isn’t a one-time acceptance test. It’s a maintenance habit, and most founders drop it the moment the app ships.

Run a weekly patch check to confirm dependencies and platform updates are current.
Schedule a quarterly health check covering logging, backup restores, and access reviews.
Commission an annual vulnerability scan or external audit, with results feeding a documented remediation log.
Require a restore test every time backup infrastructure changes, and run acceptance testing after every major release.

Alpine Excellence’s guidance for Swiss SMEs frames this as a risk-based ongoing program rather than a launch-day checkbox, and suggests security spend scale with the risk the app actually carries rather than a flat industry number. Keep a running remediation log ranked by severity so nothing critical sits unaddressed for months because nobody owns the follow-up.

How Ampersand Labs Applies This Checklist in Practice

Ampersand Labs is a Zurich-based studio where senior developers stay on a project from the first consultation through handover to ensure continuity and quality control.

On the NeuroMynds project, the team delivered a founder’s site built to be fast, safe, and ready to onboard paying subscribers from day one, with the access and deployment controls above baked in rather than retrofitted.
Senior involvement from kickoff means the person who scoped your authentication model is still there when it ships, not replaced by whoever was free that sprint.

How Ampersand Labs Can Help You Run This Checklist

There are other ways to get here: hire a freelance auditor for a one-off scan, or lean on your existing agency to self-certify against a checklist like this one. Both work, but neither gives you a senior engineer who stays accountable after the report gets filed. Ampersand Labs runs security into the build itself through MVP and web app development engagements, so the checks above are acceptance criteria from day one rather than a scramble before launch.

If your app is already live, monthly support covers the ongoing cadence this article describes: patch checks, quarterly health reviews, and a remediation log that actually gets worked, not just written. For teams still evaluating a vendor or checking one already under contract, Ampersand Labs can run a focused checklist review or short audit against the exact items above. Browse the case studies to see how this plays out on real projects, then reach out to scope a review or a monthly support proposal.

Sources

FAQ

What Is the Most Important Item on a Web App Security Checklist?

Multi-factor authentication on admin accounts and a tested backup restore are the two items that block the most damage, and both should be non-negotiable before go-live.

How Often Should a Hired Web App Be Security Tested?

Run a weekly patch check, a quarterly internal health check, and an annual external vulnerability scan or audit, adjusting frequency upward for apps handling payment or health data.

What Should Be in a Vendor’s Data Processing Agreement?

The DPA should name every subprocessor, state where data is physically stored, describe breach cooperation duties, and reference relevant certifications like ISO/IEC 27001 where applicable.

How Do I Verify a Vendor’s Security Claims Without Technical Skills?

Ask for concrete evidence, not descriptions: certificate reports, exported logs, restore test dates, and a redacted incident summary, then check the dates are recent rather than years old.

Can Ampersand Labs Run a Security Checklist Review on My Existing App?

Yes. Ampersand Labs offers focused checklist reviews and ongoing monthly support for apps already in production, building on the senior-led approach used on projects like NeuroMynds.

Have a project this touches on?

A free 10-minute call is the fastest way to find out whether we are the right studio for it.

Book a free 10-min call

Keep reading