Security hygiene starts with a modest question: what could go wrong with this product’s data and accounts, and what evidence shows the team has reduced that risk? A copied checklist cannot answer either part.
Describe one product before choosing controls
Illustrative threat model, not a description of Pink Banana Tools or a customer system. Consider a small B2B product that stores document type, expiry date, assigned owner, reminder settings, user accounts, and an audit history. It sends reminders but does not need the original documents.
For this example, data minimisation is an early control: do not accept uploaded documents when the job can be completed with a date and a few labels. That does not remove security responsibility. It narrows the assets that need protection and makes access, deletion, backup, and incident questions easier to answer.
| Asset | Why it matters | Where it moves or rests | Owner to name |
|---|---|---|---|
| User accounts and sessions | They control access to customer workspaces. | Identity provider, browser sessions, support recovery flow | Application owner |
| Expiry records | They may reveal operational details about a customer. | Application, database, export, backup | Data owner |
| Service credentials | They can grant access to infrastructure or third-party services. | Deployment platform, secret store, runtime | Technical owner |
| Audit events | They support investigation and customer questions. | Application log and monitoring service | Operations owner |
| Backups | They support recovery but also contain customer data. | Backup provider and restore environment | Recovery owner |
Map controls to credible threats
A tiny team does not need to predict every attacker. It does need to examine ordinary paths to harm: stolen credentials, excessive access, exposed secrets, destructive mistakes, missing evidence, and support impersonation.
| Threat scenario | Likely consequence | Hygiene control | Evidence to retain |
|---|---|---|---|
| A founder’s email or hosting account is phished | Account takeover and access to product systems | Named accounts, multifactor authentication where available, recovery details kept current | Account inventory and dated access review |
| An old contractor retains production access | Unnecessary access to customer data or deployment controls | Role-based access, offboarding step, periodic review | Access list showing owner, role, reason, and review date |
| An API key appears in a repository or support screenshot | Third-party service or data access | Secret storage outside source, scoped credentials, rotation after exposure | Secret inventory, scan result, and rotation record without the secret value |
| A bad deploy deletes or overwrites records | Data loss or service interruption | Backups, restore procedure, reversible migration plan | Restore test record from a non-production environment |
| Logs contain private record text | Data exposed to more people and vendors than intended | Structured event logs with identifiers; restrict and retain only what is needed | Sample redacted log and log-access review |
| Someone asks support to change an account owner | Unauthorised account recovery or workspace takeover | Documented verification and escalation path | Recovery runbook and ticket audit trail |
Controls should be specific to the threat. MFA helps with account compromise; it does not repair an overly broad service credential. A backup can support recovery; it does not prove that recovery will work until the restore path is tested.
Prefer evidence over reassurance
A small team can maintain a compact evidence folder without publishing sensitive internals. Keep records that answer who, what, when, and whether the control was exercised.
Hygiene evidence checklist
A first security-hygiene pass
This pass is not an audit and may take longer than one work session. Stop and obtain specialist help when the architecture, data sensitivity, contract, or incident history exceeds the team’s competence.
- Draw the path for customer data from input through storage, logs, exports, deletion, and backups.
- List accounts with production, domain, repository, email, payment, and backup access. Remove access that no longer has an owner and reason.
- Review MFA options on critical services. Prefer stronger, phishing-resistant methods where the provider supports them and the team can operate recovery safely.
- Search source, deployment settings, documentation, and support material for exposed credentials. Rotate anything exposed rather than merely deleting the visible copy.
- Select a backup and restore it to an isolated non-production destination. Record what could and could not be recovered.
- Review logs for unnecessary customer content and confirm who can access them.
- Walk through account recovery and a security report arriving through support. Name who decides and who is contacted.
What the sources support, and what they do not
- CISA’s Cyber Guidance for Small Businesses recommends security ownership, incident planning, MFA, patching, and backups. The page explicitly says following its advice is not a guarantee against an incident.
- OWASP’s Secrets Management Cheat Sheet covers centralised handling, access control, least privilege, auditing, and rotation. It is implementation guidance, not proof that a particular deployment follows it.
- NIST’s CSF 2.0 resources for small businesses present cybersecurity as risk management across govern, identify, protect, detect, respond, and recover. Using the framework does not confer certification.
These sources support the direction of the hygiene practices. They do not verify your product’s settings, code, vendors, backups, access boundaries, or legal duties. That evidence has to come from the actual system and its operators.
Do not turn a hygiene pass into a security claim
Avoid “secure,” “fully encrypted,” “industry standard,” “compliant,” or certification language unless the exact claim has authorised evidence and review. Even a narrower statement must be verified. “MFA is enabled for production administrators” requires an account review. “Backups are tested” requires a restore record.
A customer-facing answer can be modest: name the data collected, the product function that needs it, the roles with production access, and the current deletion and security contact routes. Draft each sentence from the product’s evidence record rather than a reusable promise.
If a fact cannot be verified, leave it out of the customer answer and create an operations task. Do not fill the gap with broad reassurance.
Questions for the next review
- What customer data could the product stop collecting?
- Which critical account lacks a named owner, appropriate MFA, or a safe recovery route?
- Which person or service can read more than its job requires?
- Which exposed credential has been deleted but not rotated?
- Which backup has actually been restored and checked?
- Would logs help investigate an access change without exposing customer content?
- Can a customer report a concern without guessing where to write?
The claim the evidence can support
The honest security answer is often a small record: who has access, what was restored, which key was rotated, and what the product chose not to collect. That is more useful than a borrowed badge.