Compliance frameworks, explained and automated
Compliance frameworks give an organization a defined set of controls to implement and a defined way to prove it did. The frameworks published here span the federal and defense landscape today, FedRAMP, CMMC, the NIST catalogs, FISMA, and the authorization concepts around an ATO, with commercial, healthcare, education, and finance frameworks expanding the library as new pages publish. Picking the wrong one to start with wastes months; the sections below walk through how the families relate and how to choose.
What this pillar covers
This library exists so that a program office, a vendor, or an assessor can look up a single framework and get a straight answer: what it is, who needs it, what it actually requires, how long it takes, what it costs, and how ACTA automates the parts of it that are automatable. Twelve pages are published today, all federal and defense frameworks plus the two commercial frameworks, SOC 2 and HIPAA, that come up most often in the same conversations.
More is coming. The OMB memoranda that shape federal software supply chain requirements, and the wider set of commercial, healthcare, education, and finance frameworks ACTA's own policy pack library already covers, are expanding into dedicated guide pages as this pillar grows.
Every published framework page follows the same shape on purpose, so once you know how to read one you know how to read all twelve: a plain-language definition, who actually needs it, the requirements broken down by control family or level, a step-by-step authorization or certification process, honest ranges for how long it takes and what it costs, the mistakes that most commonly derail an assessment, exactly how ACTA automates the parts of it that are automatable, and how the framework relates to the ones next to it.
Which compliance framework do I need first?
The fastest way to find a starting point is to work backward from who is asking. A federal SaaS vendor with no existing authorization usually starts with FedRAMP. A defense contractor asking whether it needs a certification starts with CMMC and the CUI question underneath it. An agency ISSM standing up a new system starts with the NIST Risk Management Framework and the NIST SP 800-53 control catalog it draws from. A healthcare vendor starts with the HIPAA Security Rule, and a commercial enterprise vendor without a federal or healthcare buyer yet usually starts with a SOC 2 report, the closest thing the commercial market has to a default expectation.
Two frameworks rarely stand alone. A defense subcontractor working through CMMC is, in practice, implementing NIST SP 800-171 at the same time, since Level 2's requirements are drawn directly from that standard. A federal cloud vendor pursuing FedRAMP is building against the same NIST SP 800-53 control catalog an agency ISSM already knows from the NIST Risk Management Framework. Starting with the framework your buyer names first is the right instinct; expect the adjacent ones to follow close behind it.
Federal and defense compliance frameworks
Federal and defense compliance frameworks make up this library's first published set, twelve pages spanning the authorization concepts every program eventually runs into: FedRAMP for cloud authorization, FISMA for the underlying statutory requirement, the NIST Risk Management Framework for the authorization process itself, NIST SP 800-53 and NIST SP 800-171 for the control catalogs federal systems and defense contractors respectively implement, CMMC for defense industrial base certification with CMMC Level 2 requirements as the assessment tier most contractors face, and the DoD Cloud Computing SRG for cloud workloads inside the Department of Defense. Authority to operate and continuous ATO round out the set, covering what the authorization decision actually is and how it stays current afterward.
Commercial frameworks, and what's coming next
Commercial frameworks published today are SOC 2, the report commercial buyers most often ask for, and the HIPAA Security Rule, for anyone touching protected health information. ACTA's underlying policy pack library already extends well past what has a dedicated guide page here: healthcare packs covering HITRUST, HITECH, and FDA 524B; education packs covering FERPA, HECVAT, and COPPA; finance packs covering PCI DSS, SOX, and DORA; and the OMB memoranda that shape federal software supply chain requirements, including M-22-18's SBOM evaluation rules. Guide pages for each expand into this library over time; the packs themselves are already there.
How ACTA relates to every framework here
Every framework page here shares one automation story: ACTA's policy pack library covers all of them, each pack shipped with every license rather than sold as a separate add-on. Packs are editable YAML, so a program can tune control narratives to its own environment instead of working from a static template, and because ACTA runs on a single deterministic engine with no probabilistic component anywhere in the compliance path, the same environment analyzed twice produces the same artifacts and the same score both times, with an inspectable trail behind every result. Whichever framework you land on first, the artifacts ACTA produces, System Security Plans, POA&Ms, evidence binders, and the rest, come from the live environment rather than a document someone wrote once and never updated.
If a term on any of these pages, POA&M, boundary, cATO, is unfamiliar, the compliance glossary exists specifically to tie that vocabulary back to the document, owner, or role it names, rather than leaving it as jargon.
Federal and defense
Commercial, healthcare, education, and finance
Frequently asked questions
Do I need every framework in this library?
No. Which frameworks apply depends on who your buyers and regulators are; most organizations need two or three from this library, not all twelve, and the decision logic above walks through the most common starting points.
Are commercial and healthcare frameworks covered yet?
SOC 2 and the HIPAA Security Rule are published today. ACTA's policy pack library already spans healthcare, education, and finance frameworks including HITRUST, FERPA, and PCI DSS; dedicated guide pages for each are expanding as this library grows.
Can one organization need both a federal framework and a commercial one?
Yes, and it is common. A software vendor selling into a federal agency and a commercial enterprise in the same quarter typically needs both FedRAMP-aligned controls and a SOC 2 report, and ACTA's shared policy pack library covers both without separate tooling.
What is the difference between a framework and an authorization?
A framework, like NIST SP 800-53 or NIST SP 800-171, defines the controls an organization has to implement. An authorization, like an ATO or a FedRAMP package, is the formal decision that those controls were verified and the risk is acceptable to operate.
Does ACTA support frameworks outside this published list?
ACTA's pack library extends well beyond what has a dedicated guide page today, spanning cybersecurity, education, healthcare, finance, and container and pipeline frameworks, all editable YAML shipped with every license.
How often do these framework pages get updated?
Each framework page carries its own last-modified date tied to when its underlying data record changes, not the site's build timestamp, so the date reflects real content changes rather than routine deploys.
Do federal and commercial frameworks share any of the same controls?
Frequently, yes. Access control, audit logging, and configuration management show up in nearly every framework in this library under different names, which is why an organization with a mature program against one framework rarely starts a second one from zero.
Where do I find definitions for terms used across these pages?
The compliance glossary maps recurring terms, POA&M, authorization boundary, cATO, and others, back to the specific document, owner, or role each one names, and it is linked from the relevant framework pages as those terms come up.