Applying ISA-CMM Process Areas to Capability Appraisals
Applying ISA-CMM Process Areas to Capability Appraisals
A maturity model only produces a usable result if the appraisal method built around it is disciplined. ISSC662 coursework on the Information Security Assurance Capability Maturity Model (ISA-CMM) treats the appraisal itself as the object worth studying, not just the security controls the model eventually recommends. A source review can catalog what a maturity model measures. An appraisal has to decide how that measurement gets collected, checked, and reported back to the organization being assessed.
Why Appraisal Structure Matters
The ISA-CMM, as described by Security Horizon (2012), is a sequence of steps performed to achieve a specific, repeatable process rather than a one-time audit checklist. Process maturity, in this framing, describes the extent to which a detailed process is defined, managed, measured, controlled, and believed effective. That definition puts weight on the appraisal team's method, not only on the organization's existing controls. Two organizations with identical security controls can receive different appraisal outcomes if one has documented, repeatable processes around those controls and the other does not.
The Nine ISA-CMM Process Areas
Security Horizon (2012) organizes the ISA-CMM around nine process areas, each assigned its own capability maturity rating. The process areas split naturally into three functional groups:
- Support activities — providing training (PA01), coordinating with the customer organization (PA02), and managing the information security assurance process overall (PA09). These are the appraisal team's own readiness checks: is the assessing organization prepared and capable of performing the work in the first place?
- System assessment — specifying initial information security needs (PA03), assessing threat (PA04), assessing vulnerability (PA05), assessing impact (PA06), and assessing information security risk (PA07). This is the on-site information-gathering stage, where the appraisal team works directly with the customer to understand what is actually at risk.
- Analysis and reporting — providing analysis and results (PA08). This is where findings from the system assessment activities are consolidated into a documented information security assurance plan and a final report of findings and recommendations.
Grouping the nine areas this way clarifies the appraisal's actual workflow: get the team and customer aligned first, gather and assess the technical picture second, and only then produce recommendations.
Capability Levels: What Zero Through Five Signal
For each of the nine process areas, the ISA-CMM assigns a capability maturity level on a zero-to-five scale (Security Horizon, 2012). A high rating indicates the area is operating in compliance with the model's expectations; a low rating flags an area needing attention before it can be considered dependable. This differs from software-security-specific models covered elsewhere in the same coursework. OWASP's Software Assurance Maturity Model (SAMM) rates individual security practices from zero (unfulfilled) to three (mastery), while the Building Security in Maturity Model (BSIMM) organizes its 113 observed activities into 12 practice areas across governance, intelligence, the software development lifecycle, and deployment (McGraw, Migues, & West, 2017). The ISA-CMM's wider zero-to-five range and its focus on organizational process area, rather than individual software security activities, reflects a broader assurance scope than a software-development-focused model needs.
Where ISA-CMM Diverges from Software-Centric Models
BSIMM and SAMM both assume a software security group already exists and measure how that group's activities mature across governance, threat intelligence, secure development touchpoints, and deployment (McGraw et al., 2017; OWASP, 2018). The ISA-CMM's process areas are not scoped to software development at all — they describe an assurance appraisal of an organization's information security posture generally, whether or not the organization writes its own code. A retailer running entirely on purchased, off-the-shelf systems still has threats, vulnerabilities, and risk to assess (PA04–PA07); it does not necessarily have a software security development lifecycle to hold up against BSIMM's touchpoints. That distinction matters when choosing a model: BSIMM and SAMM answer "how mature is our secure coding practice," while ISA-CMM answers the broader question, "how mature is our information assurance process."
Applying the Appraisal Structure in Practice
In practice, the three functional groups of ISA-CMM process areas run in sequence rather than in parallel. Support activities come first because an appraisal team that has not coordinated scope, contacts, and expectations with the customer organization cannot reliably gather system-level data later. System assessment activities then proceed from the narrowest scope (specifying initial security needs) to the broadest (assessing overall information security risk), because each step depends on information gathered in the one before it — threats cannot be weighed without first knowing what needs protecting, and risk cannot be assessed without threat, vulnerability, and impact data already in hand. The analysis and reporting process area closes the loop by turning that sequence of findings into a plan and a report that the organization's stakeholders can act on. Treated this way, the ISA-CMM is less a scorecard than a project plan: a repeatable order of operations that produces a defensible, comparable appraisal regardless of which organization or system is under review.