







Building Security Assurance
Maturity Model
License
This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA.
https://bsamm.org



Introduction



The Security Assurance Maturity Model (SAMM) is an open framework to help organizations formulate and implement a strategy for security that is tailored to the specific risks they face. A serious security program cannot stop at any one part of the organization: it has to account for the endpoints people use, the infrastructure you operate, the data you hold, the processes people follow, the vendors you depend on, and the software you build. This library devotes one volume to each of those six domains. This Introduction is the volume they share.
The security landscape does not hold still. New device types, new platforms, new attacker techniques, new AI tooling and new regulation all move faster than any annual plan. SAMM is built for that: rather than a fixed checklist, it defines a way to measure where an organization stands today and to improve in deliberate, measurable increments. The resources provided will aid in:
- Evaluating an organization’s existing security assurance practices across all six domains
- Building a balanced assurance program in well-defined iterations
- Demonstrating concrete improvements to a security assurance program over time
- Defining and measuring security-related activities throughout an organization
SAMM was defined with flexibility in mind: it can be used by small, medium and large organizations, applied organization-wide, to a single line of business, or to a single team. The same four Business Functions and twelve Security Practices recur in every domain, so once you have read this Introduction, each domain guide reads the same way — only the specifics change.
The foundation of the model is the four core Business Functions, with three Security Practices tied to each. The building blocks are the three Maturity Levels defined for every Practice. As an open project, SAMM content shall always remain vendor-neutral and freely available for all to use.
Governance
Construction
Verification
Operations


IntroductionSecurity is not one problem but several, and they do not all yield to the same people, tools or habits. SAMM divides the work into six domains. An organization does not have to be equally mature in all of them — but it does have to account for all of them, because attackers will happily enter through whichever one was ignored. Each domain has its own guide; here is what each one covers.

Endpoints
Security in the devices people use — laptops, phones, tablets and the ever wider range of hardware that reaches organizational resources. It addresses how those devices are provisioned, configured, kept current and recovered when lost or compromised.
Applies to every organization — its people all use phones, laptops or tablets.

Infrastructure
Security in the systems an organization operates: servers, networks, cloud services and the platforms everything else runs on. It addresses how that estate is designed, hardened, monitored and maintained across its lifecycle.
Applies to any organization that runs servers, a website or cloud services.

Data
Security in the information an organization holds and is trusted with. It addresses how data is classified, protected, retained and disposed of, and how privacy obligations are met as information moves through systems and across boundaries.
Applies to almost every organization, and most of all those trusted with data on others' behalf.

Process
Security in the things people do: the tasks, decisions and judgment calls that no system fully automates. It addresses how human workflows — verifying an identity, handling a request, responding to an incident — are made resilient against error and manipulation, including where AI assistants now sit in the loop.
Applies to every organization — people are always making decisions that affect security.

Vendor
Security in the third parties an organization depends on — suppliers, service providers and partners woven into its supply chain. It addresses how those relationships are assessed, contracted, monitored and offboarded so that borrowed capability does not become borrowed risk.
Applies to nearly every organization, since almost all rely on outside technology services.

Software
Security in the applications and code an organization builds. It spans how teams specify, design, implement and test software, and how they respond to the vulnerabilities that surface once code is in production.
Applies to organizations that build their own software, for internal use or to license to others.
The rest of this Introduction explains the framework those six guides share: the Business Functions, the Security Practices beneath them, the Maturity Levels that let you place yourself, and how to assess and improve. Read it once, and every domain guide will be familiar.












Understanding
the Model

At the highest level, SAMM defines four critical Business Functions, and it defines them the same way in every domain. Each Business Function is a category of activities that any organization must carry out to some degree — whether it is building software, running infrastructure, handling data, managing vendors or operating the processes people follow.
For each Business Function, SAMM defines three Security Practices — twelve in all — the independent areas in which an organization can build assurance. The Practices keep the same names across all six domains; what changes from one domain to the next is the specific activities that sit beneath them. So a reader who learns the twelve Practices here will recognize them in every volume.
For each Security Practice, SAMM defines three Maturity Levels as Objectives. Each Level is characterized by a successively more sophisticated Objective, defined by specific activities and more stringent success metrics than the previous level.
Governance
Governance is centered on how an organization manages its security activities across the board. It covers the cross-cutting concerns that apply to every domain — strategy and measurement, policy and compliance, and the education that keeps people equipped to act securely.
Construction
Construction concerns how an organization sets goals and builds security in from the start. Whether the thing being built is software, a device fleet, a data pipeline, a vendor relationship or a human process, it covers understanding the threats, specifying security requirements and designing to meet them.
Verification
Verification is focused on how an organization checks and tests what it has built or arranged. It covers reviewing designs, reviewing the thing as actually implemented or configured, and testing it in its operating environment to confirm the controls are present and effective.
Operations
Operations entails how an organization runs and sustains what it has deployed. It covers managing the issues that arise, hardening the operating environment around each asset, and monitoring and maintaining security over the full lifecycle.



IntroductionMaturity Levels
Each of the twelve Security Practices has three defined Maturity Levels and an implicit starting point at zero. The details for each level differs between the Practices, but they generally represent:
Notation
Throughout this document, the following capitalized terms will be reserved words that refer to the SAMM components defined in this section. If these terms appear without capitalization, they should be interpreted based on their context:
- Business Function also as Function
- Security Practice also as Practice
- Maturity Level also as Level, Objective












Applying the
Model

Each of the twelve Security Practices have three Maturity Levels. Each Level has several components that specify the critical factors for understanding and achieving the stated Level. Beyond that, these prescriptive details make it possible to use the definitions of the Security Practices even outside the context of using SAMM to build an assurance program.
OBJECTIVE
The Objective is a general statement that captures the assurance goal of attaining the associated Level. As the Levels increase for a given Practice, the Objectives characterize more sophisticated goals in terms of building assurance for an organization’s work.
ACTIVITIES
The Activities are core requisites for attaining the Level. Some are meant to be performed organization-wide and some correspond to actions for individual project teams. In either case, the Activities capture the core security function and organizations are free to determine how they fulfill the Activities.
RESULTS
The Results characterize capabilities and deliverables obtained by achieving the given Level. In some cases these are specified concretely and in others, a more qualitative statement is made about increased capability.
SUCCESS METRICS
The Success Metrics specify example measurements that can be used to check if an organization is performing at the given Level. Data collection and management is left to the choice of each organization, but recommended data sources and thresholds are provided.
COSTS
The Costs are qualitative statements about the expenses incurred by an organization attaining the given Level. While specific values will vary for each organization, these are meant to provide an idea of the one-time and ongoing costs associated with operating at a particular Level.
PERSONNEL
These properties of a Level indicate the estimated ongoing overhead in terms of human resources for operating at the given Level.
- Practitioners — Individuals performing the hands-on design, implementation and operational work in a domain
- Architects — Individuals performing high-level design work and large-scale system engineering
- Managers — Individuals performing day-to-day management of staff
- Testers & Assessors — Individuals performing quality assurance, testing and pre-release verification
- Security Auditors — Individuals with technical security knowledge related to the assets being produced or operated
- Business Owners — Individuals performing key decision making on the organization and its requirements
- Support & Operations — Individuals performing customer support or direct technical operations support
RELATED LEVELS
The Related Levels are references to Levels within other Practices that have some potential overlaps depending upon the organization’s structure and progress in building an assurance program. Functionally, these indicate synergies or optimizations in Activity implementation if the Related Level is also a goal or already in place.



IntroductionBy measuring an organization against the defined Security Practices, an overall picture of its built-in security activities emerges. Because the Practices are the same in every domain, one assessment method applies to all six — and running it across every domain is what shows an organization the full breadth of what it does and does not yet do.
The process of conducting an assessment is simply evaluating an organization to determine the Maturity Level at which it is performing. The extent to which performance is checked will vary with the drivers behind the assessment, but in general there are two recommended styles:
- Lightweight — the assessment worksheets for each Practice, provided in each domain guide, are evaluated and scores are assigned based on the answers. This is usually sufficient for an organization mapping its existing program into SAMM to get a quick picture of where it stands.
- Detailed — after the worksheets are complete, additional audit work checks that the Activities prescribed by each Practice are actually in place, and the Success Metrics are collected to confirm the organization is performing as expected.

Scoring is straightforward. After answering a Practice’s questions, the answer column indicates the Level, given by affirmative answers on all questions above the markers to the right of the column. Where existing activities straddle a boundary — all of Level 1, say, plus a few beyond it — annotate the score with a “+” (for example, “1+”). An organization performing every Activity for a Practice, including some beyond the scope of SAMM, would score “3+”.




An assessment produces a Maturity Level for each of the twelve Security Practices in each of the six domains. A scorecard collects all of those onto one page: a single snapshot of the whole organization’s security posture at one point in time, drawn directly from an evaluation against the model.
Read down a column to see how mature one domain is across all twelve Practices; read across a row to see how consistently a single Practice is applied from one domain to the next. Gaps stand out at a glance — a Practice that is strong in Software but absent in Vendor, or a whole domain that trails the rest. A score of 0 means the Practice is unfulfilled in that domain; 1, 2 and 3 are the Maturity Levels, and a “+” marks activity beyond the Level shown.
Endpoints | Infrastructure | Data | Process | Vendor | Software | |
|---|---|---|---|---|---|---|
| Strategy & Metrics | ||||||
| Policy & Compliance | ||||||
| Education & Guidance | ||||||
| Threat Assessment | ||||||
| Security Requirements | ||||||
| Secure Architecture | ||||||
| Design Review | ||||||
| Implementation Review | ||||||
| Security Testing | ||||||
| Issue Management | ||||||
| Environment Hardening | ||||||
| Monitoring & Maintenance |
Each scorecard stands on its own as a picture of the present. Re-running the assessment later and filling a fresh scorecard shows how the picture has changed, but the snapshot itself needs no time interval to be useful.



IntroductionOne of the main uses of SAMM is to help an organization build a security assurance program — and a complete program spans all six domains, not just one. That process is straightforward, and generally begins with an assessment of where the organization currently stands.
To give organizations a starting point, SAMM provides roadmap templates for several common types of organization — an Independent Software Vendor, an Online Service Provider, a Financial Services Organization and a Government Organization — set out on the pages that follow. Each maps the twelve Practices to a target Maturity Level in each phase. Many organizations can adopt the closest match and tailor it; others build a custom roadmap the same way. Because the twelve Practices are shared across every domain, a template describes the shape of a program — which Practices to lead with — that an organization then applies within each domain, weighted by where its real risk lies.
Roadmaps consist of phases in which several Practices are each improved by one Level. A phase might raise the weakest, most exposed Practices across several domains at once, or concentrate on the one domain that carries the most risk. After each phase, the roadmap is adjusted for what was actually accomplished, and the next phase begins.





| Phase 1 | Phase 2 | Phase 3 | Phase 4 | |
|---|---|---|---|---|
| Strategy & Metrics | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Policy & Compliance | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | ||
| Education & Guidance | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Threat Assessment | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Requirements | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Secure Architecture | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | ||
| Design Review | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Implementation Review | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Security Testing | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Issue Management | ![]() | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Environment Hardening | ||||
| Monitoring & Maintenance | ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
RATIONALE
An Independent Software Vendor builds and sells software products and the services around them. Its sharpest risk sits in the Software domain — a single vulnerability ships to every customer at once — but the same product depends on the endpoints its developers use, the infrastructure that builds and hosts it, the customer data it handles, the third-party components in its supply chain, and the processes by which it is released and supported.
Initial drivers to limit common vulnerabilities reaching customers lead to early concentration on Implementation Review and Security Testing, applied first to the product and then to the build and release pipeline in the Infrastructure domain.
Shifting toward preventing errors at the source, the organization adds Security Requirements and Threat Assessment over time, so that product features and the vendor dependencies they pull in are both specified with security in mind.
To limit the damage of any issue that does escape, Issue Management is ramped up into a coordinated disclosure process that spans the product, its hosting and the data it touches. As the organization matures, Monitoring & Maintenance knowledge-transfer is added so customers and operators can run and update the product securely.
ADDITIONAL CONSIDERATIONS
Outsourced or distributed development
When development is spread across contractors or acquired teams, restricted code access shifts weight from Implementation Review toward Security Requirements, and raises the Vendor and Process domains — the contracts, access controls and hand-offs that govern who may touch what.
Software delivered as a service
A vendor that also hosts its product inherits the Online Service Provider's exposure: advance Environment Hardening and Monitoring & Maintenance in the Infrastructure domain earlier than a purely on-premises product would need.
Embedded or high-assurance products
Where a defect is expensive or dangerous to fix in the field, weight Secure Architecture and Design Review earlier, and extend the same rigor to the data and process domains that surround the product.



Introduction| Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 | |
|---|---|---|---|---|---|
| Strategy & Metrics | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Policy & Compliance | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Education & Guidance | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Threat Assessment | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Requirements | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | ||
| Secure Architecture | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |||
| Design Review | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Implementation Review | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Testing | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Issue Management | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Environment Hardening | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Monitoring & Maintenance | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
RATIONALE
An Online Service Provider runs a service its customers reach over the internet. Its infrastructure and data are continuously exposed, so the Infrastructure and Data domains carry as much weight as the Software that implements the service.
Early phases concentrate on Environment Hardening and Security Testing of the live service, together with Design Review, because the fastest wins come from closing off the internet-facing surface.
Because the service holds customer data continuously, Data-domain activities — classification, protection and retention — advance alongside, and Policy & Compliance grows to meet the obligations that come with holding that data.
Monitoring & Maintenance is developed steadily throughout: a service that is always on needs always-on detection, and the endpoints and processes of the operations team are part of that picture. Over time, Threat Assessment and Security Requirements deepen so new features and vendor integrations are reasoned about before they are exposed.
ADDITIONAL CONSIDERATIONS
Multi-tenant platforms
Where one platform serves many customers, tenant isolation raises Secure Architecture and Data-domain controls; a single flaw can cross customer boundaries.
Heavy reliance on third parties
A service assembled from many external APIs and providers should advance the Vendor domain earlier — its security is only as strong as the parties it calls out to.
Regulated data
Holding regulated data pulls Policy & Compliance and Data-domain retention and disposal forward, closer to the Financial Services shape below.




| Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 | |
|---|---|---|---|---|---|
| Strategy & Metrics | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Policy & Compliance | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Education & Guidance | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Threat Assessment | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Requirements | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Secure Architecture | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Design Review | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | ||
| Implementation Review | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Testing | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Issue Management | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Environment Hardening | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Monitoring & Maintenance | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
RATIONALE
A Financial Services Organization operates under heavy regulation and holds highly sensitive data, so Policy & Compliance and the Data domain lead its roadmap from the first phase.
Strategy & Metrics and Education & Guidance are established early, because a large, audited organization needs a defined program and a trained workforce before deep technical work pays off.
Secure Architecture and Environment Hardening advance quickly across the Infrastructure and Endpoint domains — the estate is large, mixed and a frequent target — while the Verification Practices build steadily, since assurance must be demonstrable to auditors rather than merely asserted.
The Vendor and Process domains matter acutely here: much financial loss enters through a supplier relationship or a manipulated human process, so Issue Management and process controls are matured deliberately.
ADDITIONAL CONSIDERATIONS
Legacy estates
Long-lived core systems constrain how fast the Infrastructure and Software Practices can move; roadmaps often need a separate track for legacy versus new build.
Fraud and social engineering
Because attackers target people and payments directly, weight the Process domain — identity verification, dual control, exception handling — earlier than a purely technical view would suggest.
Multiple regulators
Organizations answering to several regulators should push Policy & Compliance and Strategy & Metrics furthest, so one program can evidence many obligations at once.



Introduction| Phase 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 | Phase 6 | |
|---|---|---|---|---|---|---|
| Strategy & Metrics | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Policy & Compliance | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Education & Guidance | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Threat Assessment | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Requirements | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Secure Architecture | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Design Review | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Implementation Review | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Security Testing | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Issue Management | ![]() | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
| Environment Hardening | ![]() ![]() | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() | |
| Monitoring & Maintenance | ![]() ![]() ![]() | ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() | ![]() ![]() ![]() ![]() ![]() ![]() |
RATIONALE
A Government Organization typically operates at scale under public scrutiny and formal mandates, with longer planning horizons — hence a six-phase roadmap that advances deliberately across all six domains.
Policy & Compliance and Security Requirements lead, because activity is mandate-driven and must be specified and auditable from the outset, while Security Testing and Education & Guidance are established early to build a baseline across a large, distributed workforce and estate.
Infrastructure and Endpoint hardening advance steadily, reflecting a large and varied estate that is a standing target. The Data and Vendor domains are matured through the middle phases — public bodies hold sensitive citizen data and depend on long procurement chains.
Monitoring & Maintenance is brought to full maturity last, once the underlying controls are in place for there to be something worth monitoring.
ADDITIONAL CONSIDERATIONS
Shared services across agencies
Where infrastructure or services are shared between bodies, Secure Architecture and the Vendor domain rise in importance; one weak participant exposes the others.
Procurement-driven delivery
When most delivery is contracted out, the Vendor and Process domains carry much of the risk; build assessment and oversight of suppliers into the roadmap early.
Citizen-facing services
Public-facing services inherit the Online Service Provider's exposure — advance Environment Hardening and Monitoring & Maintenance for those systems ahead of the general schedule.












Case
Studies

How a logistics company used the model to decide where its next increment of security effort should go.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareNorthwind Freight is a mid-sized logistics company: a few thousand staff, a fleet of trucks, a customer portal, a warehouse network and a long list of partners who touch its shipments. Security had always been handled reactively, department by department, until a phishing call that re-routed a real payment forced the question of how mature the company actually was. Rather than answer domain by domain, Northwind assessed itself against all six at once — and found, as most organizations do, that its strengths and gaps did not line up with where it had been spending.
The first assessment
A lightweight assessment scored each of the twelve Practices in every domain. Software came out middling — the portal team tested before release but rarely threat-modeled. Endpoints were weakest: laptops were imaged once and never touched again, and there was no way to wipe a lost device. Infrastructure was uneven, strong in the data center and ad hoc in the cloud accounts teams had spun up on their own.
Data scored low on retention and disposal — nothing was ever deleted — even though access controls were reasonable. Vendor was the blind spot the payment fraud had exposed: partners were onboarded on trust and never reviewed again. Process, the domain no one owned, was where the actual incident lived: no one had agreed how to verify a caller before changing payment details.
Phase one — the quick wins
Northwind did not try to fix everything. The first phase raised the lowest-risk, highest-exposure Practices by a single Maturity Level each. Endpoints got centralized management and remote wipe. Process got a written identity-verification step for any change to payment or payroll data — one that works for a human agent and for the AI assistant the help desk had just started piloting. Vendor got a basic intake review so no new partner was connected without one.
None of these were sophisticated. They were the ad hoc-to-repeatable step that Level 1 describes, and together they closed the specific hole that had cost the company money.
Phase two — deepening
With the bleeding stopped, the second phase went after effectiveness. Software added threat assessment to the portal’s design work. Infrastructure brought the stray cloud accounts under a hardened baseline and started monitoring them the way the data center already was. Data introduced a classification scheme and, for the first time, a retention schedule that actually deleted things. Vendor moved from a one-time intake form to periodic re-assessment of its most critical partners.
Each improvement was scored, so Northwind could show its board a before-and-after scorecard across all six domains rather than a vague assurance that things were better.
Where they landed
Two years in, Northwind was not uniformly mature, and did not aim to be. It had pushed the domains that carried its real risk — Process, Vendor, Endpoints — furthest, and left others deliberately at a level that matched their exposure. The point of the model was never a perfect score; it was a shared language for deciding where the next increment of effort should go.
It also proved to be a moving target. New device types, new AI tooling in the help desk, new partners and new regulation all shifted the picture faster than any annual plan could keep up with. The assessment became something Northwind repeated, not something it finished — which is exactly how the model is meant to be used.



IntroductionHow a cash-strapped hospital system rebuilt after ransomware by spending only where a dollar bought the most risk reduction.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareMeridian Health runs three hospitals and a dozen clinics on margins measured in single digits. Security had always lost the budget fight to clinical equipment — until ransomware encrypted the electronic health record over a weekend, diverted ambulances for two days, and forced staff back to paper. The board’s question afterward was not how to become world-class, but what Meridian could actually afford that would reduce the chance of it happening again.
The first assessment
A rapid assessment across the six domains found the money had gone to the wrong places. Infrastructure was the open wound: one flat network let the ransomware reach everything, and the backups that existed had never been test-restored. Endpoints were a museum — nursing workstations years behind on patches and medical devices running operating systems their makers no longer supported and Meridian could not legally modify.
Data access was tighter than expected, hardened by years of HIPAA audits, and Software barely applied since almost nothing was built in-house. Process was the quiet culprit: there was no rehearsed incident plan, and the first phishing email had reached a clerk never trained to doubt it.
Phase one — stop the bleeding cheaply
Meridian chose the highest-risk, lowest-cost moves first. Multi-factor authentication and tested, offline backups came before anything glossy. The flat network was carved into segments so a compromised clinic could no longer reach the hospital core. Because the legacy medical devices could not be patched, they were isolated behind their own segment with tight access rules — a compensating control rather than a fix.
Process gained a one-page, rehearsed ransomware playbook and short, mandatory phishing training for every badge holder.
Phase two — build the muscle
With survival addressed, the second phase raised Monitoring & Maintenance so someone would actually see an intrusion in progress, and formalized Threat Assessment so new clinical systems were reasoned about before they were plugged in. Vendor management tightened around the imaging and records suppliers whose remote-support connections had been standing open.
Where they landed
Meridian never became a bank, and never tried to. It spent its limited dollars where they bought the most risk reduction — Infrastructure, Endpoints and Process — and left the rest deliberately modest. The model gave the board a way to see that its spending finally matched its risk, and a schedule to revisit as devices aged, because in healthcare the estate is never static and the next unsupported device is always arriving.




How a startup that outran its own security turned a SOC 2 demand into a real program without killing its speed.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareLarkfield went from twelve people to two hundred in three years, and its security kept none of that pace. The wake-up call was mundane: a routine test by a prospective enterprise customer found an object-storage bucket exposing customer data, and that deal — with three more behind it — now hinged on a SOC 2 report Larkfield did not have.
The first assessment
The assessment read like the company’s history. Infrastructure had grown by improvisation: cloud accounts spun up per team, identity permissions granted broadly and never revoked, the exposed bucket only the most visible symptom. Vendor was a genuine blind spot — dozens of SaaS tools and third-party APIs adopted on company cards, none reviewed, several with access to production data. Data had never been classified, so no one could say with confidence what the bucket had held.
Software, the thing Larkfield actually sold, was in better shape — engineers tested and reviewed code — but Endpoints and Process trailed, with laptops unmanaged and access requests handled over chat.
Phase one — the SOC 2 forcing function
Rather than treat the audit as paperwork, Larkfield used it to sequence real work. The first phase brought the cloud accounts under a hardened baseline with least-privilege identity, put customer data behind a classification scheme, and stood up a basic vendor intake so no new tool reached production without a review. Enrolling laptops in management was almost an afterthought, but it closed a real gap.
Phase two — make it durable
The second phase turned one-time audit fixes into habits: continuous monitoring of the cloud estate, periodic re-review of the most critical vendors, and threat assessment folded into the design of new features so speed no longer meant blind spots. Security requirements became part of shipping rather than a gate bolted on at the end.
Where they landed
Larkfield got its SOC 2, and the deals. More useful was the change in reflex: the same move-fast culture now carried a lightweight check at each step instead of an annual reckoning. Its roadmap looked much like the Online Service Provider template — Infrastructure and Data first — but the company revisited it every quarter, because at its growth rate the estate it was securing was never the one it had last assessed.



IntroductionHow a factory whose real disaster is downtime, not disclosure, secured a plant floor it could not simply reboot.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareHalstead Tooling makes precision components on a plant floor that runs three shifts. When ransomware crossed from the front-office network onto the factory network and idled the line, the cost was counted not in leaked records but in hours of stopped production and a genuine worry about machine safety. For Halstead, an outage — not a breach — was always the disaster.
The first assessment
Assessing across the six domains surfaced a risk model unlike an office’s. Infrastructure was the crux: the IT and operational-technology (OT) networks were effectively one, so an ordinary phishing click could reach programmable controllers that cannot be rebooted or patched on demand. Vendor was close behind — the machine-tool suppliers kept always-on remote connections for support, a convenient door no one watched.
Data mattered less here than availability, and Software was mostly purchased, but Process carried real weight: change on the plant floor is governed by safety, and security fixes had to respect that no control could be altered lightly.
Phase one — separate and control
The first phase drew a hard line between IT and OT, so a compromise in the office could no longer reach the floor. Vendor remote access was pulled behind brokered, time-boxed connections that someone approved and logged. Neither change touched a single machine’s programming, which kept the safety engineers comfortable, yet both sharply cut the paths an attacker could take.
Phase two — see and sustain
The second phase added monitoring tuned to the OT environment, where “normal” looks nothing like an office network, and hardened the aging servers that bridged the two worlds. Threat assessment was extended to ask, for each new piece of connected equipment, what it could reach if it were turned against the plant.
Where they landed
Halstead’s program will always read differently from a bank’s: it optimizes for keeping the line running safely, not for secrecy. It pushed Infrastructure, Vendor and Process furthest and left others deliberately lighter. And because every new machine arrives with its own software and its own remote-support habits, the assessment became a standing part of procurement rather than a one-time project.




How a retailer learned its attack surface included every third-party script and supplier it embedded.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareBrightwater Retail sells across forty stores and a busy web shop. The breach that started its program was invisible for weeks: a third-party script on the checkout page had been quietly altered to skim card numbers as customers typed them. The card networks noticed before Brightwater did, and a PCI investigation followed.
The first assessment
The assessment traced the trouble to the seams between Brightwater and the parties it relied on. Vendor was the weakest link — the checkout page pulled in a dozen third-party scripts, any of which could change without notice, and the skimmer had ridden in on one. Data was both the prize and the exposure: cardholder data flowed through more systems than anyone had mapped. Endpoints included in-store point-of-sale terminals, some running long past their support dates.
Infrastructure and Software were middling, and Process was informal but not the origin of this particular incident.
Phase one — close the checkout
The first phase went straight at the bleeding: the third-party scripts on payment pages were inventoried, cut to the minimum, and locked down so an unapproved change could no longer execute. Cardholder-data flows were mapped and narrowed to shrink what any single compromise could reach, and the oldest terminals were replaced or segmented off.
Phase two — widen the guard
With the immediate hole closed, the second phase set up ongoing review of the vendors and scripts the storefront depended on, brought monitoring to the payment paths, and made security requirements part of onboarding any new marketing or checkout tool — the usual way new scripts had crept in.
Where they landed
Brightwater’s roadmap leaned on Vendor, Data and Endpoints, where its real risk lived, and treated PCI as a floor rather than the goal. The lasting change was accepting that its attack surface included every script and supplier it embedded — a surface that shifts with each new campaign, and so has to be watched continuously rather than certified once a year.



IntroductionHow a decentralized institution that cannot mandate compliance secured itself through influence instead.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareCoastal State University is less an organization than a federation: hundreds of departments, thousands of staff and tens of thousands of students, each guarding its autonomy. Its reckoning came when a research group’s data — years of work with real commercial and national-security value — was quietly exfiltrated through a departmental web application no central team knew existed.
The first assessment
Assessing a place that resists central control was itself the lesson. Software was a sprawl of departmental and research-built applications, unmaintained and unmapped, the breached app among them. Data ranged from ordinary student records under FERPA to sensitive research that drew patient, sophisticated adversaries. Process reflected the culture — open by default, with security seen as something that got in the way of teaching and research.
Endpoints were a free-for-all of personal devices, while Infrastructure and Vendor were comparatively well run by the central IT group that did hold authority.
Phase one — influence, not mandate
Coastal could not simply order compliance, so its first phase worked through incentives and services: an inventory that finally found the shadow applications, an easy path to retire or adopt the riskiest ones, and data classification that let the university concentrate protection on the research that warranted it. Security requirements were offered as help to grant-funded projects rather than imposed as a checkpoint.
Phase two — raise the floor
The second phase lifted the baseline everywhere the center could reach: review of departmental applications before they went online, guidance and light-touch management for the devices touching sensitive data, and threat assessment focused on the research groups most likely to be targeted.
Where they landed
Coastal accepted that uniform maturity was neither possible nor the point; it raised the domains carrying real risk — Software, Data and Process — while leaving the long tail governed by influence. The model gave a decentralized institution a shared language its many fiefdoms could actually agree on, and a way to keep revisiting the parts of itself it could never fully see.




How an organization with almost no budget closed its biggest risks with the cheapest, most disciplined moves.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareOpen Harbor supports vulnerable communities on a budget where every dollar is already spoken for and much of the workforce is volunteers who come and go. Its threat was out of proportion to its size: a sophisticated phishing campaign, aimed at the very people it protected, tried to turn the organization’s own accounts into a way to reach them.
The first assessment
The assessment had to respect that almost nothing could be bought. Endpoints were a mix of personal and donated laptops, unmanaged and inconsistently updated. Process was shaped by volunteer turnover — accounts outlived the people who used them, and there was no routine for verifying who was asking for what. Vendor risk hid in the free and discounted tools the nonprofit depended on, some holding sensitive data on the people it served.
Data sensitivity was extreme even though its volume was small, while Software and Infrastructure barely applied to a cloud-and-laptops operation.
Phase one — free first
Open Harbor’s first phase spent almost no money and closed real risk: multi-factor authentication on every account, a simple joiner-and-leaver routine so departed volunteers lost access promptly, and short training tuned to the specific phishing its people faced. The most sensitive constituent data was consolidated into the few well-secured tools it already had and pulled out of the rest.
Phase two — sustain with little
The second phase focused on what a tiny team could keep doing: a short list of vetted tools rather than an ever-growing sprawl, basic monitoring of the accounts that mattered most, and a habit of asking, before adopting any new free service, what it would hold and who could see it.
Where they landed
Open Harbor will never have a security team, and built a program that assumes it. It concentrated on Endpoints, Process and Vendor — the risks its people and tools actually presented — and accepted deliberate gaps elsewhere. Its story is the reassuring one in the set: even with almost no budget, the biggest risks often yield to the cheapest, most disciplined moves, provided they are chosen by risk and kept up.



IntroductionHow a law firm protected privileged client data across a mobile, partner-owned estate it could not simply mandate.
Endpoints
Infrastructure
Data
Process
Vendor
SoftwareCalder & Boyd is a mid-size law firm — eighty partners and associates, a support staff, and a duty of confidentiality that is not merely a regulatory obligation but the core of the business. Its reckoning came the ordinary way: a phishing email, opened on a partner’s laptop during travel, gave an intruder a foothold in the matter files. Nothing was encrypted and no ransom was demanded — the data was quietly copied and, months later, offered for sale. For a firm whose product is discretion, the exposure of client secrets was the worst outcome imaginable.
The first assessment
A quiet assessment across the six domains found the firm’s risk concentrated exactly where its work happens. Endpoints were the weak point: partners’ laptops and phones travelled everywhere, carried copies of highly sensitive matter files, and — because partners are owners rather than employees — had never been brought under consistent management. Data was both the prize and the exposure, duplicated across mailboxes, laptops, and a shared drive with little classification and no retention discipline, so no one could say where a given matter’s secrets actually lived.
Vendors added a surface the firm did not control — the e-discovery platform, the cloud practice-management system, and the outside services that handled overflow copying all held client data under agreements no one had reviewed for security. Infrastructure and Software were modest and largely outsourced, and Process, though informal, was not where this breach began — even if the phishing that started it was a reminder of how close that domain sits.
Phase one — manage the devices, protect the files
The firm did not attempt the wholesale IT takeover its partners would have resisted. The first phase secured what mattered most: multi-factor authentication on every account, and enrolment of the laptops and phones that touch client data into management that could enforce encryption and wipe a lost device — presented to partners as protection of client confidence rather than corporate control. The most sensitive matter files were consolidated into the firm’s best-secured system and pulled out of scattered mailboxes and local drives.
Phase two — govern the data and the vendors
With the immediate exposure reduced, the second phase built the disciplines a firm is actually judged on. Data gained a simple classification tied to client sensitivity and a retention schedule that finally closed old matters rather than keeping everything forever. The most critical vendors — the e-discovery and practice-management providers above all — were assessed against a short security standard and held to it in their contracts, so borrowed capability stopped being unexamined risk. Brief, mandatory training taught staff to recognize the client-impersonation and wire-fraud attempts that target legal practices.
Where they landed
Calder & Boyd did not become a technology company, and its partners kept their autonomy. What changed was that the firm could show clients — and its own malpractice insurer — that the confidentiality it promised was backed by controls, concentrated in the domains that carried its real risk: Endpoints, Data, and Vendor. The model gave a partnership that resists central mandates a shared, professional language for the few security decisions that were not optional, and a schedule to revisit as new matters, new devices, and new legal-technology tools continually reshaped what it had to protect.




https://bsamm.org