A practical security baseline for a 20-person SaaS company

A 20-person SaaS company is large enough to hold meaningful customer data, production credentials and business-critical infrastructure, but usually too small to maintain a large dedicated security team. That makes prioritization more important than tool count. The objective is to establish controls that the company can operate consistently, explain to customers and improve as it grows.

This baseline draws on the NIST Cybersecurity Framework 2.0 Small Business Quick-Start Guide, CISA small-business and Secure by Design guidance, CIS Controls Implementation Group 1 and OWASP's Application Security Verification Standard. It is an operating framework, not a claim of certification or a substitute for a formal risk assessment where one is required.

1. Define ownership before buying security tools

NIST CSF 2.0 groups cybersecurity outcomes into Govern, Identify, Protect, Detect, Respond and Recover. For a small SaaS company, that can be translated into a simple question: who owns each of those outcomes when there is no dedicated security department? One person may coordinate the program, but the responsibilities still need names and escalation paths.

• Name one accountable security owner, even if security is not their full-time role.
• Identify the systems and data that would materially damage the company if compromised or unavailable.
• List the external services the company depends on for identity, source control, cloud hosting, payments and customer operations.
• Write down who can approve production access, revoke accounts and lead an incident response.

2. Put identity controls first

NIST and CISA both prioritize multi-factor authentication and strong account hygiene. For a SaaS company, the highest-value accounts are usually the identity provider, email, cloud administration, source-control organization, CI/CD, finance tools and production consoles. These should be the first places where MFA and least-privilege access are enforced.

• Require MFA wherever the service supports it, with phishing-resistant methods for high-value administrative access where feasible.
• Use a company password manager and unique credentials rather than shared passwords.
• Avoid shared administrator accounts so that actions remain attributable.
• Create a rapid offboarding process that revokes identity, source-control, cloud and application access together.
• Review account-recovery methods so that weak recovery paths do not undermine otherwise strong MFA.

3. Know what the company actually runs

Patching and access control are difficult when the team does not know which systems it owns. A lightweight asset view should cover managed laptops, cloud accounts, code repositories, CI/CD pipelines, production environments, important SaaS tools and dependencies that can affect customer-facing services.

CIS Controls IG1 is useful here because it focuses on essential cyber hygiene rather than assuming a mature enterprise security organization. The principle is straightforward: build enough inventory and ownership to know what must be protected and maintained.

4. Patch quickly, but define who owns the risk

NIST recommends regular software and operating-system updates, with automatic updates where appropriate. A SaaS team should combine that hygiene with explicit ownership for application dependencies, base images, cloud services and internet-facing components that cannot simply update themselves.

• Enable automatic endpoint and common software updates where operationally safe.
• Track vulnerabilities in product dependencies and container/base images.
• Prioritize weaknesses that affect internet-facing systems or privileged access.
• Document the exception when a critical patch cannot be applied quickly, including the temporary mitigation and owner.

5. Protect production access and secrets

The production environment should not be accessible simply because someone is an engineer. Use least privilege, limit direct database access, keep secrets out of source code and make deployment changes traceable through an auditable workflow. The smaller the team, the more useful a consistent deployment path becomes because it reduces reliance on informal access.

6. Log the events that answer incident questions

CISA includes logging among its core defensive practices. A small team does not need to centralize every possible event on day one, but it should retain the logs needed to answer basic questions during an incident: who authenticated, who changed production, what privileged action occurred and whether suspicious access succeeded.

• Identity-provider and administrative authentication events.
• Source-control and CI/CD administrative changes.
• Cloud audit activity for privileged actions.
• Production application events that support security investigation.
• A retention period that gives the team enough history to investigate an issue discovered late.

7. Back up data — then prove that recovery works

NIST and CISA both emphasize backups, but a configured backup is not the same thing as recoverability. Teams should perform restoration tests and understand how much data could be lost and how long recovery of critical services is expected to take.

The recovery plan should include more than the primary database. Infrastructure configuration, essential secrets-recovery procedures, customer-critical file storage and the ability to rebuild supporting services may matter just as much during a real outage.

8. Encrypt endpoints and important data flows

NIST recommends full-disk encryption for laptops and tablets. For a SaaS company, managed endpoints should use device encryption, while customer-facing services should use HTTPS/TLS and appropriate encryption for stored sensitive data. Encryption does not replace access control, but it reduces exposure when devices or storage are lost or accessed improperly.

9. Use application-security requirements instead of vague best practices

OWASP ASVS provides concrete verification requirements across authentication, authorization, session management, cryptography, secure communications, configuration, secrets, logging and error handling. A small SaaS team can use those requirements as a review checklist without claiming formal ASVS compliance unless it has actually been verified.

• Review authorization at every sensitive object and administrative action.
• Keep credentials, tokens and signing keys out of repositories and client-visible code.
• Validate untrusted input and use safe data-access patterns.
• Use secure session and cookie configuration.
• Avoid exposing stack traces, internal secrets or sensitive identifiers through errors.
• Treat security logging as a product requirement, not only an infrastructure concern.

10. Prepare for incidents before the first serious one

A small company may never need a large incident-response organization, but it still needs a decision path. The team should know who can disable an account, rotate credentials, isolate a system, restore data, contact customers and involve legal or regulatory advisers when circumstances require it.

A one-page runbook is more valuable than a large document nobody has rehearsed. Test the runbook with a simple scenario — for example, a privileged account takeover or production credential leak — and use the gaps to decide the next security investment.

A practical 30-day baseline

• Week 1: enforce MFA, establish a password manager, inventory admin accounts and document offboarding.
• Week 2: inventory endpoints, cloud services and repositories; assign patch ownership; verify endpoint encryption.
• Week 3: test backup restoration, review production access and confirm critical logging coverage.
• Week 4: write and exercise an incident runbook, then review the product against a focused application-security checklist.

The baseline should be operable, not impressive

A 20-person SaaS company does not become secure by buying the same tools as a large enterprise. It becomes more defensible by operating a small set of controls consistently: strong identity, known assets, timely patching, controlled production access, useful logs, tested recovery, encrypted endpoints and deliberate application-security review. The next layer should be added because the risk or customer requirement justifies it, not because a checklist has more boxes available.

What to check before you commit

1. Start with identity, ownership and production access before expanding the toolset.
2. Maintain enough asset inventory to know what must be patched and protected.
3. Test restores instead of assuming backups are recoverable.
4. Use application-security requirements such as OWASP ASVS as a review framework, not an unverified compliance claim.
5. Rehearse a short incident runbook before the team needs it under pressure.

A note on measurement

Teams that treat small-team SaaS security as an engineering project usually measure the wrong thing. Instrument the business outcome first — cycle time, cost per transaction, resolution rate, revenue retention — then work backwards to the technical metrics that move it.