Skip to content
>_ITDITDWeb Security Platform

Learn

#security basics#organizations#access management#incident response

The security baseline for mid-to-large organizations: the standard foundation for teams

The security baseline mid-to-large organizations should standardize: SSO, enforced MFA, revoking departed access, secrets infrastructure, SBOM, CI/CD protection, SIEM and incident response — in priority order, through this site's operational lens.

Published 2026-06-11 Updated 2026-06-11 8 min read

For: mid-to-large organizations that develop and operate as a team and want the security baseline that's considered standard at their scale. If you're solo or small, see the indie / small-operator baseline. No attack steps here — just the foundation standard at scale, in priority order.

This site's view: we're small — this maps what the standard requires at scale

Honestly, this site is a small operation, so day to day we run the indie / small version. This article maps the foundation the industry standard demands once you scale up. The underlying principle is the same — "fill the higher-priority layers first, as systems." What grows in an organization isn't flashy technology but people and process. Phishing, stolen credentials, neglected departed access, and third-party compromise become the leading causes the larger you get.

Tier 0 — identity governance

SSO · enforced MFA · joiner/mover/leaver lifecycle · least privilege

Tier 1 — secrets and supply chain

secrets infra · short-lived creds · SBOM · signing/provenance · CI/CD protection

Tier 2 — app and infra

secure SDLC · SAST/DAST · WAF · network segmentation · IaC scanning

Tier 3 — detect and respond

central logs/SIEM · alerting · IR plan/runbooks · drills · DR restore

cross-cutting — people and governance

owners/team · policy · training · vendor management · separation of duties · audit

The org priority map. Same skeleton as the indie version, but each layer becomes a 'program,' and people/governance run through all of it.
people
the biggest way in at scale (phishing, etc.)
leavers
neglected access is a classic hole
third parties
supply chain gets targeted
systematize
from one-person to standing program

Tier 0 — govern identity (first)

This is the org-scale equivalent of the indie "keys to the kingdom." At scale, those keys are your identity provider (IdP) and admin accounts. Lose them and the whole organization falls.

1

Centralize auth with SSO

Stop per-service logins; unify authentication with SSO (SAML/OIDC) so you can see and disable accounts from one place.
2

Enforce phishing-resistant MFA org-wide

Make passkeys/hardware keys (FIDO2) the standard and mandatory, no exceptions. SMS and opt-in settings are holes. Guard admin accounts most.
3

Automate the access lifecycle (joiner/mover/leaver)

Grant on hire, review on transfer, revoke immediately on departure. Automate with SCIM so neglected departed access disappears — the most common hole at scale.
4

Least privilege and privileged access management

Use role-based access (RBAC) scoped to the minimum. Don't grant admin rights standing — give them just-in-time, time-bound.

Tier 1 — make secrets and supply chain infrastructure

This is the indie "secrets and code" run as continuous infrastructure. Hand-managed .env files don't scale.

1

Adopt a secrets-management platform

Centralize secrets in a secrets manager (Vault, a cloud KMS / Secrets Manager). Enforce org-wide "never hardcode into code or config" (→ .env and secrets).
2

Move to short-lived, dynamic credentials

Reduce long-lived static keys in favor of automatically issued and expired short-lived credentials. Standardize rotation and audit logging.
3

SBOM, signing and provenance

Inventory your dependencies (SBOM) and sign artifacts with provenance to detect tampering. Dependency CVE monitoring like osv-scanner is the on-ramp.
4

Protect the CI/CD pipeline itself

The build environment and pipeline are high-value targets. Apply least privilege, isolate secrets, and detect tampering. Supply-chain example → the Codecov breach.

Tier 2 — app and infra hardened by default

This promotes the indie "app itself" into process and infrastructure standards — assured by systems, not one person's review.

1

A secure development process (SDLC)

Require code review and automated tests; wire SAST/DAST into CI to machine-detect the classic holes (SQLi, XSS, SSRF, IDOR).
2

Defense in depth (WAF, segmentation, zero trust)

Mitigate known attacks with a WAF, segment the network, and assume no implicit internal trust (zero trust) to stop lateral movement after a breach.
3

Treat infrastructure as code, securely

Scan IaC for misconfiguration, use hardened base images, and keep a patch discipline that doesn't leave known CVEs (→ not falling behind on CVEs; the cost of unpatched → Equifax).

Tier 3 — make detection and response a function

Assume breach. Hold "notice it, stop it, recover from it" as a function with owners.

1

Centralize logs and detect anomalies

Aggregate logs from every system (SIEM, etc.) and alert on dangerous signs — and define who watches, and when.
2

Have an incident-response plan and runbooks

Document "who does what, in which order" (runbooks), on-call, contact trees, and external-reporting obligations. If it leaked, assume it all leaked — rotate everything.
3

Drill that you can actually execute it

Run tabletop exercises. A plan only matters once it's used.
4

Disaster recovery and tested restores

Beyond 3-2-1, encrypted, offsite backups, set recovery objectives (RTO/RPO) and periodically test that you can actually restore.

Cross-cutting — people and governance (where scale really bites)

Beneath the technology sits a foundation organizations specifically need. If this is weak, every control above collapses through a human hole.

Common failures

  • tools deployed but no owner
  • departed-employee access and old tokens never reviewed
  • no security training, so one phishing email is enough
  • third-party vendor risk never assessed

The foundation to standardize

  • a security owner/team and policies
  • regular access reviews and separation of duties (avoid concentrated privilege)
  • company-wide security training (especially anti-phishing)
  • vendor / third-party risk management, data classification, and audits if needed (SOC 2 / ISO 27001)

Relation to the indie version

The right way to see it: same skeleton, each layer simply grows from a "task" into a "program." You can start small and systematize in stages. So internalize the priority order in the indie / small version first, then, as the team grows, lift each layer here into "continuous operation with an owner" — a continuous path, not a different road.

How this site thinks about it

This site is small, so day to day we apply the indie foundation to ourselves (dedicated server for separation, separate keys, secrets never in git, automated dependency CVE monitoring, offsite backups). This article is a map of "what the standard demands once you scale." The consistent message: before the flashy work, fill the higher-priority layers as systems. The order principle doesn't change with size.

FAQ

QWhat changes most from the indie version?
A

Controls shift from 'a checklist one person runs' to 'programs with owners.' The priority order (identity → secrets and supply chain → app and infra → detect and respond) is the same, but each layer is run continuously as a system, with people and process.

QWhat should an organization lock down first?
A

Identity governance: centralize auth with SSO, enforce phishing-resistant MFA org-wide, and provision/deprovision access with the employee lifecycle (especially revoking departed-employee access immediately). At scale, neglected departed accounts become the biggest way in.

QIs dependency scanning (osv-scanner, etc.) baseline for orgs too?
A

Yes, and at scale you go a step further: produce a software bill of materials (SBOM), sign artifacts with provenance, and protect the CI/CD pipeline itself. Supply-chain compromise is a classic way attackers target organizations.