banto.

The Technical Risk Scorecard
for B2B SaaS

A practical, opinionated scorecard for B2B SaaS founders and CTOs. If you cannot confidently check off the majority of these items, your platform is carrying technical risk that surfaces as a failed enterprise security questionnaire, a due diligence red flag during your Series A, or an AI governance gap that spooks a regulated buyer.

Luke Williams, Founder

Years in Security & Technical Architecture

Former UK Government Cybersecurity Research Lead

0 / 24

How to interpret your core score (out of 24)

0 – 10: Rescue Mission Stop building features and fix the foundation. You are one failed security questionnaire or due-diligence review away from a serious problem that costs real money.

11 – 17: Danger Zone You need a Technical Risk Roadmap. Your team has a foundation, but key risks will surface during your next fundraise, enterprise deal, or scaling event.

18 – 24: Strong Posture Your foundations are solid. Expand into the deep-dive items and keep improving.

Infrastructure-as-Code

4 core · 4 deep dive

Goal: Eliminate "snowflake" servers and manual configuration drift.

All cloud resources are defined in Terraform, Pulumi, or CloudFormation — not created via console clicks ⚠️ Deal Killer

Run terraform plan (or equivalent) against your live environment. If it wants to create resources that already exist, you have drift and manual provisioning.

Terraform state is stored remotely with locking enabled (e.g., S3 + DynamoDB, GCS + Cloud Storage) ⚡ Quick Win

Check your backend configuration. If state lives in a local .tfstate file or an unversioned bucket without locking, concurrent runs will corrupt your state.

Environments (dev, staging, prod) are structurally identical, differentiated only by variables ⚠️ Deal Killer

If your staging environment uses a different resource topology than production, you are not actually testing deployments before they hit prod.

No secrets are hardcoded in IaC files or committed to version control ⚡ Quick Win

Run git log --all -p | grep -iE "(password|secret|api_key|token)" against your IaC repo. If anything surfaces, rotate those credentials immediately.

⋅

IaC modules are versioned and pinned — no floating latest or untagged main references

Grep your module sources for ref=main or missing version constraints. Every module reference should point to a specific tag or commit SHA.

⋅

A static analysis tool (Checkov, tfsec, or Snyk IaC) runs on every pull request

Check your CI config for an IaC scanning step. Misconfigurations like public S3 buckets and overly broad security groups should be caught before merge, not after an incident.

⋅

Drift detection runs on a schedule and alerts when live infra diverges from code

Someone on your team should be able to show you the last drift report. If no one knows what this means, manual console changes are going undetected.

⋅

Infrastructure changes require peer review via pull request — no one can terraform apply to production directly

Check whether your CI/CD service account is the only entity with write access to production. If individual engineers hold production credentials, you have a single-point-of-failure problem.

Struggling with IaC? Book a free Diagnostic Call

CI/CD Pipeline

3 core · 4 deep dive

Goal: Every change ships through an automated, repeatable, auditable pipeline.

Every commit to the main branch triggers an automated build, test, and deploy pipeline

Open your CI dashboard and check whether the last 20 deploys to production all went through the pipeline. If any were manual SSH + git pull operations, that is a red flag.

Deployments to production use a rollback-safe strategy (blue-green, canary, or rolling update) ⚠️ Deal Killer

Ask your team: "How long does it take to roll back a bad deploy?" If the answer is more than 5 minutes or involves manual steps, your deployment strategy needs work.

Branch protection rules enforce passing CI, at least one approval, and no direct pushes to main/production branches ⚡ Quick Win

Go to your repository settings right now. If any engineer can push directly to main without a review, your deployment guardrails are incomplete.

⋅

Pipeline runs are fully reproducible — build artifacts are immutable and tagged to a specific commit SHA

Can you deploy last Tuesday's exact build right now? If the answer is "probably, let me check," your build process has non-deterministic dependencies.

⋅

CI/CD secrets (API keys, deploy tokens) are stored in the pipeline's secret manager, not in repo files or environment scripts

Check your CI config for inline secrets, base64-encoded tokens, or .env files committed to the repo. Secrets should come from GitHub Actions Secrets, GitLab CI Variables, or an external vault.

⋅

Container images are built from a pinned base image, scanned for CVEs, and pushed to a private registry

Check your Dockerfiles for FROM node:latest or FROM python:3. Every base image should use a specific digest or version tag, and images should be scanned with Trivy, Grype, or your registry's built-in scanner.

⋅

Pipeline execution time is under 15 minutes for the full build-test-deploy cycle

Slow pipelines kill developer velocity. Check your average pipeline duration over the last month. If it exceeds 15 minutes, identify bottlenecks (test parallelization, layer caching, artifact reuse).

CI/CD a bottleneck? Book a free Diagnostic Call

III

Security Hardening

5 core · 4 deep dive

Goal: Make your attack surface as small as possible and prove it to auditors.

MFA is enforced on all human accounts — especially the root/owner account of your cloud provider ⚡ Quick Win

Check your IAM console. The root account should have a hardware MFA token. Every engineer and admin account should require MFA. No exceptions.

Secrets are managed through a dedicated service (AWS Secrets Manager, HashiCorp Vault, Doppler) with automatic rotation enabled

Grep your application code and config for hardcoded database passwords, API keys, or connection strings. If secrets are in environment files checked into Git, they need to be migrated immediately.

All data is encrypted at rest (database, object storage, EBS volumes) and in transit (TLS 1.2+ enforced) ⚠️ Deal Killer

Check your RDS, S3, and EBS configurations for encryption settings. Test your endpoints with ssllabs.com — anything below an A rating needs attention.

Network security groups follow deny-by-default: no 0.0.0.0/0 ingress rules except on load balancers serving public traffic

List all security groups with 0.0.0.0/0 ingress. If SSH (port 22) or database ports (3306, 5432, 27017) are open to the internet, close them today.

A documented incident response plan exists, and at least one tabletop exercise has been conducted in the past 12 months ⚠️ Deal Killer

Ask your team: "If our database was breached at 2 AM, who gets paged, and what is the first action?" If there is no clear, documented answer, you do not have an incident response plan.

⋅

IAM follows least-privilege: no wildcard (*) actions or resources in production policies

Run AWS IAM Access Analyzer or gcloud asset analyze-iam-policy. If any policy grants Action: "*" or Resource: "*" in production, it is over-permissioned.

⋅

Dependency vulnerability scanning (Dependabot, Snyk, or Renovate) runs automatically and blocks merges on critical/high CVEs

Check whether your repositories have automated dependency PRs. If no one on your team can name the last critical vulnerability that was patched, scanning is either absent or ignored.

⋅

Cloud audit logging is enabled (CloudTrail, GCP Audit Logs) and logs ship to a tamper-proof, centralised location

Verify that CloudTrail is enabled in all regions, logs are sent to a dedicated logging account or immutable S3 bucket, and log file validation is turned on.

⋅

An external penetration test or vulnerability assessment has been performed in the past 12 months

If you have never had a pentest, or the last one was more than a year ago, schedule one. Enterprise customers and investors will ask for the report.

Security gaps keeping you up at night? Book a free Diagnostic Call

Scalability & Reliability

3 core · 4 deep dive

Goal: Survive 10x traffic and recover from failure without waking the CEO.

Database backups run automatically, are stored cross-region, and have been tested with a successful restore in the past 90 days ⚠️ Deal Killer

Backups that have never been restored are assumptions, not backups. Run a restore to a test environment this week and time it. Document the RTO.

Structured observability is in place: centralised logging, application-level metrics, and distributed tracing

Can you answer "why was the API slow at 3 PM yesterday?" with your current tooling? If not, you need structured logs (not just console.log), metrics (Prometheus/Datadog), and traces (OpenTelemetry).

The application can survive the loss of a single availability zone without downtime ⚠️ Deal Killer

Check whether your compute, database, and cache are deployed across at least 2 AZs. If your entire stack is in us-east-1a, a single AZ outage takes you offline.

⋅

Application services run behind a load balancer with health checks, not on a single instance with a public IP

If your production app is a single EC2 instance and it dies, so does your product. Check whether you have an ALB/NLB with health check endpoints that actually verify application readiness.

⋅

Auto-scaling is configured with appropriate min/max bounds and scales on application-level metrics (request latency, queue depth), not just CPU

Check your scaling policies. If they only trigger on CPU > 80%, you will miss memory pressure, request queuing, and slow database queries that degrade user experience.

⋅

Alerting is configured with clear severity levels, escalation paths, and an on-call rotation

Check your alerting rules. If every alert goes to the same Slack channel with the same urgency, alert fatigue will ensure the critical ones get ignored.

⋅

A load test has been run against production-like infrastructure in the past 6 months, and the results informed capacity planning

Use k6, Locust, or Artillery to simulate 5x your current peak traffic. If your system falls over or response times degrade beyond SLA, you need to address bottlenecks before the next growth spike.

Worried about your next scaling event? Book a free Diagnostic Call

Cloud Cost Management

2 core · 3 deep dive

Goal: Know where every dollar goes and stop paying for what you don't use.

Budget alerts are configured at 50%, 80%, and 100% thresholds with notifications going to Slack or email ⚡ Quick Win

Check AWS Budgets or GCP Billing Alerts. If you find out about a cost spike by looking at the monthly invoice, you are reacting weeks too late.

Non-production environments automatically shut down outside business hours or are powered by spot/preemptible instances ⚡ Quick Win

If your staging and dev environments run 24/7 at full capacity, you are burning 65-70% of that spend for nothing. Implement scheduled scaling or instance scheduler policies.

⋅

Every cloud resource is tagged with at least Environment, Team, and Service for cost attribution

Pull your cost report and check how much spend is "untagged." If more than 20% of your bill cannot be attributed to a specific service or team, you have a visibility problem.

⋅

Right-sizing recommendations have been reviewed in the past quarter (AWS Compute Optimizer, GCP Recommender)

Most startup workloads run on instances that are 2-4x larger than needed. Check Compute Optimizer — if the recommendations have never been reviewed, you are likely over-provisioned.

⋅

Orphaned resources are cleaned up: unused EBS volumes, stale snapshots, idle load balancers, and unattached Elastic IPs

Run AWS Trusted Advisor or a tool like Infracost. Orphaned resources from old experiments and deleted services quietly add hundreds per month to your bill.

Cloud bill out of control? Book a free Diagnostic Call

Compliance & Resilience

3 core · 4 deep dive

Goal: Pass any audit, survive any departure, and own your data.

An asset inventory exists: you can produce a list of all cloud accounts, services, databases, and third-party integrations within 30 minutes ⚠️ Deal Killer

Every compliance framework starts with "know what you have." If generating a complete inventory takes days of manual work, you are not audit-ready.

A "bootstrap" runbook exists — if your lead DevOps engineer disappeared tomorrow, a new hire could rebuild the stack from the repo ⚠️ Deal Killer

Ask yourself: is there a single person who is the only one who knows how to deploy, recover, or configure critical systems? If the answer is yes, that's not a staffing problem. It's a business continuity risk, and investors will flag it.

Critical data is portable — no hard dependency on proprietary services without an export or migration path

Identify your three most critical data stores. For each one, can you export the data and restore it on a different provider within 48 hours? If the answer is no, you have vendor lock-in that will concern any acquirer or investor.

⋅

Data residency is understood and enforced: you know which regions store customer data and can prove it

Check your database, S3, and CDN configurations. If a European customer asks "where is my data stored?" you should be able to answer with specific regions and evidence, not guesswork.

⋅

Evidence collection for SOC 2 or ISO 27001 controls is automated (via Vanta, Drata, Sprinto, or equivalent)

Manual evidence collection for compliance audits consumes weeks of engineering time and still misses gaps. If you are targeting enterprise customers, automate this before the first audit request arrives.

⋅

Access reviews are performed quarterly: who has access to what, and is it still justified?

Pull your IAM user list and last-activity dates. If former contractors or employees still have active credentials, or if engineers have access to systems they no longer work on, revoke them now.

⋅

AI/ML workloads (LLM APIs, vector databases, GPU instances) are cost-monitored, access-controlled, and have fallback providers

If your product relies on an LLM API, check: is usage tracked per-customer? Are API keys scoped and rotated? Is there a fallback if your primary provider has an outage or changes pricing? In 2026, AI infrastructure is production infrastructure.

Audit or compliance deadline approaching? Book a free Diagnostic Call

VII

AI Governance

4 core · 4 deep dive

Goal: Ship AI-enabled features without creating uncontrolled risk, data leakage, or compliance gaps.

All LLM and AI API keys are scoped per-service, stored in a secrets manager, and rotated on a schedule ⚠️ Deal Killer

Check your codebase and environment variables. If a single OpenAI or Anthropic API key is shared across services, hardcoded, or has never been rotated, you have an access control gap that any security questionnaire will flag.

Customer data sent to third-party AI models is inventoried, minimised, and governed by a clear data processing policy ⚠️ Deal Killer

Trace every API call that sends data to an external model. Do you know exactly what customer data is included in prompts? Is PII stripped or redacted before it leaves your environment? Enterprise buyers and regulators will ask.

Prompt injection defences are in place for any user-facing AI feature ⚠️ Deal Killer

If your product accepts user input that is passed to an LLM, test it: can a user manipulate the prompt to extract system instructions, bypass access controls, or access other users' data? Input validation and output filtering are non-negotiable.

AI model usage is logged, attributed per-customer, and cost-monitored with alerts for anomalies ⚡ Quick Win

Can you answer "how much did Customer X's AI usage cost last month?" If not, you cannot price AI features sustainably, detect abuse, or respond to billing disputes. Instrument this before it becomes a P&L problem.

⋅

AI model outputs are validated and constrained — the system cannot return arbitrary content to end users without guardrails

Review your AI output pipeline. Are responses filtered for harmful content, checked against a schema, or bounded by a set of allowed actions? Unvalidated model output is equivalent to unsanitised user input.

⋅

A fallback strategy exists if your primary AI provider has an outage, deprecates a model, or changes pricing

If OpenAI goes down at 9 AM on a Tuesday, what happens to your product? Identify single-provider dependencies and document a switchover plan, even if it is manual. Provider lock-in is a business continuity risk.

⋅

Third-party AI models and libraries are inventoried as part of your software supply chain, with version pinning and licence review

Treat AI dependencies like any other third-party code. Are model versions pinned? Do you know what licence governs each model you use? Can you produce this inventory for an auditor or enterprise buyer on request?

⋅

Role-based access controls govern who can modify AI system prompts, fine-tuning data, and model configurations in production

Check your deployment process: can any engineer change a system prompt in production without review? Prompt changes are functionally code changes and should go through the same approval and audit trail.

Shipping AI features without governance? Book a free Diagnostic Call

How to interpret your core score (out of 24)

Infrastructure-as-Code

CI/CD Pipeline

Security Hardening

Scalability & Reliability

Cloud Cost Management

Compliance & Resilience

AI Governance

Could not check off everything?