The situation. You just won a contract, or a subcontract from a prime, that carries a security clause. You have a dozen laptops that people bought themselves, a consumer cloud tenant somebody set up during the seed round, a Slack workspace, and no IT department. Somebody has sent you a spreadsheet with 110 requirements on it. This article is about the order to build in, because the sequence matters far more than the tooling, and four of the decisions are expensive to reverse.
There is a version of this problem that is genuinely hard and a version that is mostly self-inflicted. The hard version is that federal security requirements assume an organization that already has IT: a directory, managed devices, centralized logs, a defined boundary around sensitive data. A twenty-person startup has none of that, because none of it was necessary to build the product.
The self-inflicted version is building the environment in the wrong order and paying to undo it. We see this repeatedly: a team stands up laptops and a productivity suite first because people need to work, adds identity six months later when someone asks about multi-factor authentication, and then discovers that every access control, every audit trail, and every piece of evidence they need has to be rebuilt on the new foundation. The technical work was not wasted, exactly. It was just done twice.
This is the build order we use, why each step comes where it does, and what to decide before you spend money.
First, read your actual contract
Before any of the technical work: find out what data you will handle. This single question determines most of the cost, and a surprising number of teams start buying licensing before they answer it.
- Federal Contract Information (FCI): information provided by or generated for the government under a contract, not intended for public release. The bar is FAR 52.204-21, fifteen basic safeguarding requirements. A well-configured commercial cloud tenant is generally adequate.
- Controlled Unclassified Information (CUI) is the higher bar. If DFARS 252.204-7012 is in your contract, you are agreeing to implement NIST SP 800-171 (110 requirements), to report cyber incidents within 72 hours, and to ensure any cloud service handling that data meets the FedRAMP Moderate baseline or equivalent.
Those are different projects with different budgets. The clause list in your contract tells you which one you are in. If you have a prime, ask them directly what data will flow to you and under what clauses. Get it in writing, because “we might send you CUI eventually” and “you will receive CUI at kickoff” produce very different architectures.
One thing worth stating plainly given the current moment: CMMC Phase 2 was suspended on July 13, 2026, and third-party certification assessments cannot currently be required on new work. That has changed the deadline pressure, but it has changed nothing about DFARS 252.204-7012 or NIST 800-171, both of which remain in force and are enforced through self-assessment and the score you affirm in SPRS. We wrote up what the suspension actually changed separately. For a startup building from scratch, the practical effect is favorable: you can build properly instead of racing a certification date.
The build order
1. Identity and directory — before anything else
Every other control is expressed in terms of identity. Access control, multi-factor authentication, least privilege, separation of duties, session timeout, audit attribution, deprovisioning — all of them presuppose that there is an authoritative answer to “who is this person and what are they allowed to do.”
Build the identity layer first and everything after it attaches cleanly. Build it fourth and you re-do the three things that came before.
Concretely: a real directory (Entra ID or Active Directory, depending on where you are heading), single sign-on for every application that supports it, phishing-resistant multi-factor authentication, defined role groups rather than per-person permissions, and a documented joiner-mover-leaver process. That last one is not a technical control and it is the one assessors ask about most often, because it is where small companies actually fail. The contractor who left in March still has access in September.
The reversibility problem: migrating identity providers after you have built access control, conditional access policies, and audit trails on top of one is among the most disruptive things you can do to a small company. Decide once, deliberately.
2. The data boundary — decide what is in and, more importantly, what is out
Before you provision anything else, decide where controlled data will live and draw a line around it. Everything inside the line inherits the compliance burden. Everything outside it does not.
This is the single most consequential decision in the entire program, because scope is cost. A startup that lets controlled data spread across its general productivity tenant, its engineering SaaS stack, three chat tools, and everyone’s laptop has made its entire company the assessment boundary. A startup that defines a specific enclave for that data, and can demonstrate the data does not leave it, has a much smaller thing to secure, document, and defend.
The corollary that teams under-use: deliberately exclude things. An engineering environment that never touches controlled data can be out of scope, if you can show the separation holds. That takes architecture, not policy language.
This is also where the cloud question gets answered. If DFARS 7012 applies and you will handle CUI, your environment needs to meet the FedRAMP Moderate baseline or equivalent, which in practice points most teams at a government-community offering. If you are FCI-only, commercial is usually fine. We covered the specific trade-offs in GovCloud vs GCC High for defense startups. The short version is that the two are not interchangeable, and the right answer depends on whether your workload is infrastructure or productivity.
The reversibility problem: moving controlled data across a boundary later is a migration with chain-of-custody questions attached. Cheap to decide now, expensive to change in month eight.
3. Endpoints — managed, hardened, and company-owned
Now the laptops. Not before, because a managed endpoint needs an identity to be managed against.
What this means in practice: company-owned devices enrolled in management (Intune, JAMF, or equivalent), disk encryption enforced and verifiable, endpoint detection and response deployed everywhere, a hardened configuration baseline applied from a recognized source (CIS Benchmarks or DISA STIGs rather than a baseline you invent), and patching that is measured rather than assumed.
The hard part is rarely technical. It is that people are using personal machines and have been since the company started. Retrofitting management onto a personal laptop is a conversation about privacy, ownership, and what the company can see, and it goes badly if it happens by surprise in month seven. Buy company devices as part of the buildout and the problem disappears. Try to enroll personal machines later and it becomes a people problem you will spend real political capital on.
4. Logging and retention — turn it on before you need it
This is the step teams skip, and it is the only one where skipping it destroys something you cannot recover.
You cannot generate audit history retroactively. If you enable centralized logging in month eight, you have no evidence for months one through seven. An assessor looking for a year of audit trail will find eight months, and the gap is not something you can paper over.
So: centralize logs early, from identity, endpoints, cloud control plane, and network. Set retention to match the framework you are targeting rather than the default your tooling ships with. Make sure someone actually reviews alerts, because “we collect logs” and “we monitor” are different claims and only one of them survives a question.
The cost argument is straightforward: logging infrastructure is cheap relative to the cost of an assessment finding that you cannot demonstrate historical control operation.
5. Productivity and collaboration, inside the boundary
Email, documents, chat, file sharing, ticketing: configured with compliance licensing where required, with external sharing controls that actually restrict, data-loss-prevention rules for the controlled data types you handle, and retention policies aligned to your obligations.
This comes fifth rather than first because the boundary decision in step 2 determines which tenant these live in, and the identity work in step 1 determines how people access them. Provisioning productivity first is exactly the ordering mistake that causes rework.
6. Policy, procedure, and the evidence pipeline
Documentation last, because documentation describes reality and writing it before the environment exists produces a binder that says something untrue.
What matters here is less the policy library (every consultancy has templates) and more the evidence pipeline. Assessors ask you to demonstrate that a control operated, not that a policy exists. If producing that demonstration means a person manually assembling screenshots the week before an assessment, you have built a reconstruction exercise that will recur every year and erode engineering time each time.
Design it so the evidence is a byproduct of the environment running normally: access reviews that generate their own artifacts, automated configuration reporting, log retention that is queryable, ticketing that records approvals. This is the difference between a compliance program that costs you two weeks a year and one that costs you two months.
The four decisions that are expensive to reverse
If you take nothing else from this: get these four right the first time, because they are the ones that force rework.
- Identity provider and directory architecture — everything references it.
- Data boundary and tenant choice — moving controlled data later is a migration, not a config change.
- Device ownership and management model — retrofitting management onto personal machines is a people problem.
- Logging and retention posture — you cannot create history after the fact.
Everything else (which EDR vendor, which ticketing tool, which SIEM) is a preference you can change later without much pain. These four are not.
What this costs you in time
For a cloud-only startup of ten to thirty people with no legacy systems and decisive leadership: roughly three to four months to a defensible environment, then the assessment-readiness work on top.
For a company standing up a physical facility (wired networking, access control, a segmented enclave for controlled data, possibly a hardware refresh): closer to six to nine months, because construction and procurement have their own timelines that do not compress no matter how motivated you are.
The variable that moves this most is not budget. It is decision latency. Every one of the four irreversible decisions above needs an owner who can commit, and programs stall in the gap between “we should decide that” and “we decided that.”
When it makes sense to bring in help
If your team can name the four decisions above and defend the answers, you may not need a firm; you need a checklist and some focused time. Our first defense contract IT checklist is written for exactly that case.
The case for outside help is narrower and more honest than most firms will tell you. It is worth it when the environment does not exist yet and the sequencing matters (building it right once is cheaper than building it twice), when a contract deadline means the runway for learning-by-mistake is gone, or when you need the environment operated while you hire the internal team who will eventually own it.
Our greenfield IT and security buildout practice does this end to end: architecture, implementation, the enclave, the evidence pipeline, and a three-to-six-month operating period before handoff with documentation and runbooks. We would rather scope it honestly than sell you a retrofit later.
Related reading: Your first defense contract: the IT checklist · Designing a CUI enclave: seven mistakes · GovCloud vs GCC High · What the CMMC suspension changed