A FinOps Assessment perspective as a NIST CSF Community Profile
As organizations move their FinOps practices to shift-left, more of the FinOps optimization and maintenance tasks get pushed to the edge where the Engineers are. In this case, FinOps teams need to move their focus towards supporting the Inform and Operate phases of the FinOps lifecycle. Through building more formal FinOps Policies and Governance standards, FinOps teams can accelerate their iteration through the lifecycle phases to increase their practice maturity for the long run. Pulling inspiration from the Intersecting Discipline of Security, FinOps teams can solidify their position as a trusted partner to the business.
This assessment is an expansion of the existing FinOps Framework Assessment as of 7/3/25. By combining FinOps capabilities with controls found in the NIST Cybersecurity Framework, FinOps practitioners can provide a structured and proven foundation for strengthening governance for cost accountability. Additionally, treating financial risk with the same rigor as cybersecurity empowers FinOps teams to better define their policies, processes, and enforcement of best practices for the organization.
This repository is broken down into encapsulated directories, where the function of a directory reflects a core design aspect or goal of the project.
At the very beginning of this project, there was a desire to establish way to define the building blocks that would go into creating a framework and its' assessment. We quickly decided that since the project was inspired by the NIST Cybersecurity Framework (CSF), that we should also try to mirror the CSF by architecting the blocks into a logical grouping. But with a distinctly FinOps flavor.
The grouping that was selected is based on the fundamental units that we call actions, which map to the sub-categories found in the CSF. These actions are organized into capabilities from the FinOps framework, now made to correspond to categories from the CSF. And as the FinOps framework does, these are placed into domains that we correlate with functions from the CSF.
In this way, the heart of this project is located in the components/ directory. The formalism that was selected is directly represented in the folder structure of this directory. Each subdirectory being a key piece (or component) of the FinOps++ scaffolding used to construct frameworks and their assessments.
The Markdown files found in these subdirectories are navigable, allowing you to traverse the logical grouping going from Domain -> Capability -> Action for the pre-defined domains, capabilities, and actions components.
To further fashion out building blocks into something useful, we place the domains into profiles, which closely parallel the function of the profiles from CSF. While the profiles are not directly considered a component themselves, they are integral to organizing this project into usable, extensible, and reproducible schemas. With their primary use-case being to define a framework.
The assessments/ directory is where you can find subdirectories (based on the profile names) representing different frameworks supported by FinOps++. Each subdirectory containing both the markdown file detailing how a framework is put together, and the assessment worksheet used for scoring against that framework. The worksheet is current an excel doc that can be easily downloaded from this repository and potentially convert to other cell-based, excel-like products (such as google sheets).
These subdirectories will be the primary entry point for most people using the FinOps++ project as the assessment is the primary product for it. The framework markdown and worksheet link to the different components used to create it as needed. With the hope of making it easy to trace out how a framework is designed to work (i.e what concerns a framework is trying to address).
At the very beginning of this project, there was a desire to establish a way to define the components that went into an assessment in such a way that ensured that each component was verifiable correct and that the information used for that component was as reusable as possible. To meet this goal, we choose to use yaml to create strict specification files that could be used to generate the components of a framework.
These specifications can be found in the specifications/ directory, in subdirectories that exactly echo those in components/. If fact, these specifications are directly used to generate the files found in the different components subdirectories (as well as the assessments found in assessments/). More of the generating process can be read about below in Generating commands below.
Note
The serialization number for a file uses the schema xxx.yaml with enough 0s before the ID to pad out the length of the file name to 3 digits.
Assisting in the goals that motivated the creation of the specifications, the tools/ directory was setup to house all the custom programming scripts and tools used on the specifications. The main "product" of this directory being the finopspp CLI tools. You can read more about this tool, and how to get started with it in CLI Tool below.
This project is only as useful as it is understandable. So chief amongst our goals is ensuring that ideas are cleanly explained and that expectations and clearly set. The guidelines/ directory is our attempt at bringing this goal to life.
This folder includes direction and explications on a range of topics, with the goal of being more in-depth than this README. From how assessments are designed, to how changes are to be made for this repository. And if you can't make sure to open up an Issue requesting clarification.
To aid with formatting, transforming, and using the yaml specification, we built the finopspp CLI tool. Currently, to use it you have to build it from source from this repository. To do this, please read through Developing the finopspp CLI tool in the development guide.
Below we will go through a few of the key commands this CLI tools provides. If you have the tool installed, we encourage you to play around with the tools and look at commands not discussed below, such as the finopspp version command.
The most useful commands to use with finopspp will be related to generate some aspect of the framework. Either markdown documentation or Excel files.
The most useful (or powerful) of the most useful commands offered by finopspp is the command used to generate the framework markdown and assessment worksheet files for a profile. The framework markdown files are designed to give a one-stop shop for getting an overview, in tabular format, of how a framework (generated from a profile) is logically grouped together. While the assessment worksheet is used for scoring the priority weighted maturity of an organization against action completeness for a profile.
To generate the markdown for the framework overview and assessment excel file, make sure that the profile you desire to use is included under `specifications/profiles or, if need be, create a new profile.
Then run the follow
finopspp generate assessment --profile="<desired-profile-name>"
you can run finopspp generate assessment --help to see the list of profile options. The files generated by this command can be found in assessments. Simply search in this directory for a <desired-profile-name> subdirectory. This subdirectory will include your framework markdown and assessment.
These files are designed to be generally more human readable and easier to navigate than the yaml specifications. The four components supported directly correlate with the four specification types used currently by finopspp. Which are profiles, domains, capabilities, and actions; and can be found in subdirectories of the same names under.
Note
profiles markdown files are generated and offered on an as-best-as-possible bases. This is because of the customization allowed for this type. Generally it is recommended to use the Framework markdown to get a true overview of the profiles. But we include them for the sake of compilation.
To generate the files in these folder fresh from the yaml files, you can call the following command
finopspp generate components --specification-type=<desired-spec-type>
Note
The serialization number for a markdown file uses the schema xxx.md, where xxx will match the serialization number of the yaml specification for the profile or component.
A set of utility commands that can do a number of different actions relevant to the yaml specifications. This range from showing the OpenAPI schema for the different specifications types, to basic updates of the specification from custom Pydantic models.
One of the most useful command is the validation command
finopspp specifications validate --specification-type=<desired-spec-type> <spec-id-or-all>
With this, you can validate a specific specification by ID and type. Or, by passing in all, you can validate all specification for a specific type. Validation is relatively strict, and makes uses of pydantic validator. Validation failures are logged to stderr for the user, and results in a failure return code on the command if any specifications fail to validate during a run.
Another really useful command is update, which can be called with the following
finopspp specifications update --specification-type=<desired-spec-type> <spec-id-or-all>
Based on the specification type, and corresponding pydantic derived model, you can update a specific specification by ID or all at once. The updates that work out-of-the-box are adding/removing fields. While other more complex updates, such as renaming a field or changing the order of fields in the schema, are allowed by creating custom alias for fields or by using pydantic model_serializer.
The new command will allow you to create new specification from smart defaults, which can be found, in code, under /tools/defaults.py. The new specification, created for a desired specification type, can be used as template to fill-in until the specification is in a state that is ready to be publish.
The command to create these new specification is simply
finopspp specifications new --specification-type=<desired-spec-type> <desired-id>
Important
If you are creating a new profile, make sure to select a Title for the specification that has not already been used. Otherwise this will cause a collision issues with the generate assessment command.
The only requirement is that the desired ID be unique. If it has been used previously, an error will be returned and the specification will not be created.
