A Pre-Demo-Day Security Checklist for Startups

Demo day rewards a clear story and a working product. Neither requires pretending a prototype is production-ready.

The goal of a pre-demo-day security review is not to complete an enterprise audit. It is to remove avoidable risks, describe the prototype honestly, and make sure the demo does not expose real users, credentials, or personal documents. Incubators can distribute this checklist one week before presentations and ask every team to assign an owner to unresolved items.

Need a cohort handout? Download the printable pre-demo-day security checklist.

Separate the demo from production

• The demo uses a dedicated test or sandbox environment.
• Test accounts are synthetic and clearly labelled.
• No real Aadhaar, PAN, DigiLocker, KYC, payment, health, or customer documents appear in the demo.
• API keys and secrets are stored outside source code and presentation files.
• The repository contains no committed .env file, private key, access token, or database export.
• The demo can be reset without affecting production users.

Screenshots deserve the same review as the live product. Blur or replace personal data, email addresses, internal URLs, tokens, and administrative identifiers before adding them to a deck.

Check login and account creation

• The product does not ship with a shared default password.
• Passwords, if supported, are handled by an appropriate authentication system rather than stored as plain text or reversibly encrypted values.
• Verification and one-time-password requests have abuse limits.
• Error messages do not reveal whether a sensitive account exists unnecessarily.
• Redirect and callback URLs are restricted to intended destinations.
• Test administrator accounts use credentials distinct from participant accounts.

If the team built its own authentication for the prototype, it should say so clearly and record what must change before public launch. “It worked during the demo” is not evidence that the design handles recovery, revocation, abuse, or concurrent sessions safely.

Review administrator access

• Every administrator has an individual account.
• Privileged access is limited to people who need it.
• The team can remove access when a member leaves.
• Sensitive administrative actions require recent or stronger authentication where appropriate.
• Important changes create an audit event with actor, action, target, and time.
• The demo does not expose an administrative route merely by hiding its navigation link.

One shared administrator login makes accountability impossible. Even at prototype stage, write down who has access and how it will be removed.

Test account recovery

• The team has documented what happens when a user loses their password, passkey, email account, or phone.
• Recovery does not rely only on profile facts an attacker could discover.
• Recovery links or codes expire and cannot be reused indefinitely.
• A successful recovery invalidates access that should no longer remain active.
• Users receive a clear notification when important recovery details change.
• Support staff cannot bypass recovery controls without an accountable process.

Ask one team member to test the recovery path cold. If the only person who understands it is the developer who built it, the process is not ready for users.

Minimize personal data

• Every signup field has a current purpose.
• Optional fields are visibly optional.
• The product explains why sensitive data is requested.
• The team knows which vendors or processors receive personal data.
• A user can find the relevant correction, deletion, or support path.
• The team has a retention decision for authentication and onboarding data.
• Analytics and logging do not capture passwords, tokens, one-time codes, or identity documents.

The startup DPDP checklist expands these questions. Legal obligations depend on the product and processing context; founders should obtain qualified advice rather than treating a blog checklist as legal approval.

Prepare the failure path

• The demo explains what happens when authentication fails.
• Rate limits and upstream failures produce a usable response.
• The team can revoke a session or disable a compromised account.
• A named person owns incident triage during the demo.
• The team knows how to contact each critical provider.
• The presentation distinguishes working features from mocked or planned features.

Judges often learn more from a team that explains one honest trade-off than from a team that claims every security problem is solved.

Use a simple readiness result

Mark each section:

• Green: checked and tested;
• Amber: known limitation with an owner and deadline; or
• Red: could expose credentials, personal data, privileged access, or production users.

Fix red items before the demo. Put amber items in the technical roadmap and state the limitation if it affects what judges see. Do not relabel a missing control as “planned” unless someone owns the work.

Run this across an incubator cohort

An incubation center can turn the checklist into a 60-minute clinic: 20 minutes of explanation, 25 minutes of startup self-review, and 15 minutes to identify red items and owners. For a deeper program, use the four-session identity and DPDP readiness plan.

NamoID may support suitable India-facing cohorts with sandbox access, workshops, starter resources, and mentors where available. Tell NamoID about the program, then share the organization name, cohort dates, and expected startup count in the NamoID Slack community for a quicker initial response. Formal partnership confirmation still happens through the application conversation.

Several items here are decided by your identity provider — the Indian startup auth decision guide compares the options.

NamoID is not affiliated with or endorsed by Startup India, DPIIT, DST, or the Government of India. This checklist does not provide certification, regulatory approval, or legal advice.