Building Toward CMMC Level 2 and NIST 800-171 as a Small Software Shop

When a small software shop starts looking at defense work, the first thing it runs into is not a contract, it is a security framework, and the framework arrives with a number that scares people off before they understand it. CMMC Level 2 and NIST 800-171 are the gate that defense work now passes through, and a lot of capable engineers assume that gate is sized for large firms with compliance departments and full-time auditors. We took the opposite bet, which is that a small firm building from a clean sheet can architect for these frameworks from the very first commit, and that doing so is far cheaper and far more honest than bolting security on after a contract is already in hand. This is a plain account of what those frameworks actually require, how we built toward them as a one-engineer SDVOSB, and why we think readiness designed in from day one is exactly the thing a prime or an agency should want from a small partner.

What CMMC Level 2 and NIST 800-171 actually are

Start with the underlying standard, because that is where the real substance lives. NIST Special Publication 800-171 is a public catalog of security requirements published by the National Institute of Standards and Technology, and it describes how a non-federal organization is supposed to protect Controlled Unclassified Information when that information lives on the contractor's own systems rather than the government's. The current revision organizes the work into a set of control families covering access control, audit and accountability, configuration management, identification and authentication, incident response, media protection, and the rest of the territory you would expect a serious security baseline to cover. The often-quoted figure is 110 controls, and that number is simply the count of individual security requirements a contractor handling Controlled Unclassified Information is expected to satisfy. None of this is secret or proprietary, it is a freely published government document that anyone can read, and reading it is the honest starting point for any firm that wants to build toward it.

CMMC is the verification layer that sits on top of that standard. The Cybersecurity Maturity Model Certification is the Department of Defense program that takes the requirements in NIST 800-171 and turns them into an assessable, certifiable bar that a contractor has to clear in order to handle protected information on a defense contract. Level 1 covers basic safeguarding of federal contract information, and Level 2 is the tier built directly on the 110 NIST 800-171 controls, which is why the two names get spoken in the same breath. The distinction that matters is that NIST 800-171 is the engineering standard you implement, and CMMC Level 2 is the formal assessment that an authorized third party conducts to confirm you actually implemented it. A firm can be aligned with the standard long before it ever sits for the assessment, and being clear about which side of that line you are on is the difference between honest readiness and overclaiming.

Why this matters more in 2025 and beyond

The reason every defense-adjacent software shop is suddenly paying attention is that the rules acquired teeth. For years CMMC lived in a long rulemaking process where the requirement was coming but not yet binding, and contractors could gesture at a self-attestation and move on. That changed when the program rule took effect in the latter half of 2025 and began phasing CMMC requirements into actual Department of Defense solicitations, so that the certification level a contract demands now shows up as a condition of award rather than a future aspiration. The practical effect is that a prime assembling a team for defense work can no longer treat a subcontractor's security posture as an afterthought, because the flow-down of these requirements reaches the smaller firms doing the hands-on engineering. A small shop that waits until a contract is on the table to think about any of this is already behind, while a small shop that built toward the standard in advance becomes the easy partner to add to a bid.

How a small shop architects for these controls from day one

Here is the part that working engineers actually care about, which is what building toward these frameworks looks like in real infrastructure rather than in a policy binder. We build on AWS using the Cloud Development Kit, which means our infrastructure is defined as code in Lambda, API Gateway, DynamoDB, KMS, and Cognito, and that single choice does an enormous amount of the compliance work for free. Infrastructure as code gives you configuration management and a reviewable change history by default, because every change to the environment is a diff in version control rather than a click in a console that no one remembers making, and that maps directly onto the configuration management and audit families the standard cares about. Cognito gives us a real identity and authentication layer rather than shared credentials, KMS gives us managed encryption of data at rest with keys we control, and API Gateway gives us a single audited boundary in front of the services rather than a sprawl of ad hoc entry points.

On top of that baseline we maintain a hardened variant of the stack built specifically for federal-track deployments, designed to be STIG and RMF adjacent, which is to say it is shaped by the same hardening guidance and risk management thinking the defense world uses even though the firm has not been through a government authorization. That hardened variant tightens the defaults a commercial deployment would leave loose, narrowing network exposure, enforcing least-privilege roles, and turning on the logging and retention that an auditor expects to find already running rather than enabled the week before an assessment. We also run security scanning inside the build pipeline, so that a known class of misconfiguration or vulnerable dependency is caught at the moment code is pushed rather than discovered later in a review, which is precisely the kind of continuous practice the standard rewards. Designing the pipeline this way means security is a property of how the software gets built rather than a checklist someone runs at the end, and for a small team that automation is the only way the work stays sustainable.

The honest framing for all of this is that we are building to align with CMMC Level 2 and NIST 800-171, and we are aware of these frameworks and architecting deliberately toward them, and that is a genuinely different claim from holding a certification under them. We have not completed a CMMC assessment and we do not hold an authorization, and we are not going to blur that line, because the same care that makes a system trustworthy makes a vendor trustworthy. What we can say plainly is that the architecture was designed with these controls in mind from the first commit, which is a far better position than a firm that has to re-engineer a commercial system under deadline pressure once a contract demands it.

Why building toward readiness de-risks the work for a prime or an agency

The value of all this to a prime or a contracting agency is straightforward once you see it from their side of the table. When a prime brings a small subcontractor onto a defense effort, that subcontractor's security posture becomes part of the prime's own risk, because the protected information flows downhill and the weakest environment on the team is the one an adversary or an assessor will find first. A small partner whose infrastructure was architected for these controls from the beginning is a partner that shrinks that risk instead of adding to it, since the hard structural work of identity, encryption, audit logging, and configuration management is already in place rather than promised. The expensive and slow part of security is never the policy document, it is retrofitting a system that was built without these concerns into one that can satisfy them, and a firm that skipped the retrofit by building correctly the first time hands the prime a head start rather than a liability. That is the real product a security-minded small shop offers, which is reduced integration risk and a shorter path to a defensible posture across the team.

Where we honestly stand

We will end where we began, on the truth, because a firm that built its infrastructure for trust has no business being loose with its own claims. Heinrichs Software Solutions Company is a Florida corporation and an SBA-certified Service-Disabled Veteran-Owned Small Business, active in SAM.gov under UEI SXG3SA9JMM47 and CAGE code 1ZSB5, carrying six NAICS codes with custom computer programming services as the primary, and founded and run by a US Navy veteran. We have architected our AWS infrastructure to align with CMMC Level 2 and NIST 800-171 from day one, with a STIG and RMF adjacent hardened variant for federal-track work and security scanning built into the pipeline, and we have not completed a CMMC assessment and hold no authorization, which is a line we will keep stating clearly. The point of this writeup is not to claim a credential we have not earned, it is to make the case that a small software shop can do the architectural work of readiness early and well, and that a prime or an agency looking for a veteran-owned partner who took security seriously before anyone made them is exactly the partner we have built toward becoming.