Frequently asked questions

No. BrilliantAtTheBasics.us is an independent educational resource published by inDirectIT, Inc. It is not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War or any other government agency. The official campaign page published by the DoW CIO remains the authoritative source for the campaign itself; everything else on this site — the sequencing, the implementation steps, the maturity ladder, the framework mappings, and the evidence guidance — is independent analysis.

Only three things are official: the practice titles, the campaign's stated intent, and the links to government and standards publishers. Those are labeled wherever they appear. Everything else is independent: the six-stage sequence, the 24-hour through 90-day actions, the seven-level maturity ladder, the validation checks, the operating metrics, the evidence recommendations, the framework mappings, and every downloadable asset. Independent material carries no official status and should not be represented as government guidance.

Nothing, unless you choose to email yourself a plan or a scorecard. The plan builder, both scorecards, the readiness check, and the cloud checklists all run entirely in your browser; your answers are never transmitted. If you use the optional email step, you send a name, an email address, an optional organization name, and the plan text to inDirectIT, and the form says so at the point of submission. Do not enter controlled, export-controlled, or vulnerability detail into any field on this site.

The commercial relationship is disclosed on every page rather than hidden, and the guidance is kept structurally separate from it. There is no paid placement, no vendor ranking, and no gated official-source material; where a commercial tool appears in the resource library it is labeled as a vendor tool. Commercial links appear only in a visually distinct, clearly labeled module at the end of a page, never inside the guidance itself. You should still read this the way you would read anything published by a firm that sells adjacent services: check the primary sources, which are linked on every page for exactly that reason.

Not in itself. The campaign is a statement of priority from the DoW CIO about where the Defense Industrial Base should focus. Your actual obligations come from your contracts and their flowdowns — clauses such as DFARS 252.204-7012, FAR 52.204-21, and any CMMC requirement your contracting officer includes. Read your contracts to find out what binds you. Implementing the twenty practices is worthwhile on its own merits, and it may help you meet obligations you already have, but it is not a substitute for reading the clause.

No. A CMMC Level 2 assessment evaluates 110 NIST SP 800-171 requirements against a defined system boundary, with evidence, and results in a score and an assessment outcome. The twenty practices contribute to a number of those requirements and provide evidence relevant to others, but they are a priority list rather than a control set — and several 800-171 requirements are not addressed by any of the twenty. Implementing them does not produce a score, establish readiness, or reduce the number of requirements you must implement.

DFARS 252.204-7012 requires contractors handling covered defense information to provide adequate security — implemented as NIST SP 800-171 — to report cyber incidents to the DoD within 72 hours, and to preserve and submit media and forensic information when asked. Several of the twenty practices support parts of that: backup and recovery, incident response, segmentation, and logging all contribute. None of them satisfy the clause, and the 72-hour reporting obligation in particular is a process requirement that no amount of technical implementation discharges on its own.

The twenty practices overlap with NIST SP 800-171 but are organized around risk reduction rather than around the 110 requirements. Every practice guide on this site carries mappings that state, for each requirement identifier, whether the relationship is direct, supporting, enabling, or contextual, how confident we are in the mapping, why it was made, and — importantly — what it does not claim. Use those mappings to orient. Use the requirement text itself, against your own scoped boundary, to decide whether a requirement is met.

No. A System Security Plan describes your specific system boundary, the components in it, and how each applicable requirement is implemented in your environment. This site is generic guidance about practices; it knows nothing about your systems. The plans and checklists generated here can inform the work an SSP documents, and the evidence guidance can tell you what to retain, but no output of this site is an SSP or a substitute for one.

Three things, in order. First, enforce phishing-resistant multi-factor authentication on every administrator and remote-access account — this is the single highest-value change available to most small contractors and it usually costs a few hundred dollars. Second, build one reconciled inventory of devices, identities, and applications, because every other control silently assumes it. Third, restore-test a backup of your most critical system and time it. Those three take days, not quarters, and they close the exposures that cause most real incidents.

Start with the practices that make gaps visible rather than the ones that close them: asset inventory, identity coverage, and a restore test. Each of those produces a number you did not have before, and those numbers tell you what to do next. The plan builder on this site accepts "we honestly do not know" as an answer and sequences accordingly, and the two scorecards give you a directional maturity picture in about ten minutes.

There is no honest single number, but the shape is consistent: a meaningful share of the twenty practices cost mostly attention rather than money. Phishing-resistant MFA, inventory, change review, and workforce readiness are largely configuration and discipline. Segmentation, backup architecture, monitoring, and legacy retirement carry real cost that scales with your estate. Each practice guide on this site carries an effort band and a cost band, and a small-business path describing the version worth doing when nobody's full-time job is security. Be sceptical of any quote that prices the twenty practices without first asking about your boundary and your existing licences.

A capable managed service provider can implement and operate most of the technical practices — identity, endpoints, patching, backup, monitoring, and segmentation. What does not transfer is accountability, and what is most often left unassigned is evidence. Agree in writing, per practice, who implements, who operates, who produces and retains the evidence, and who is accountable for the outcome. The last column can only ever be you. The responsibility matrix on this site exists to be filled in jointly and signed.

Generally at four points: when you need to scope a CUI boundary and the answer changes what you buy; when a migration to a government cloud environment is on the table; when a customer or contracting officer is asking for an assessment result rather than an improvement plan; and when an operational-technology change carries safety consequences that need engineering review. Everything else is usually within reach of a competent internal team or a good MSP working from material like this. This site is deliberately useful without anyone buying anything.

Differently from IT, and more slowly. Availability and safety outrank confidentiality in a plant, so the sequencing changes: know what you have, control who can reach it, and separate it from the business network before you attempt anything that touches a live controller. Use passive discovery rather than active scanning. Apply only vendor-approved patches, tested first, inside approved maintenance windows, with a tested rollback and the process owner present. Where patching is unsafe, a documented compensating control is the correct answer, not a failure. If a security action conflicts with safe operation, safe operation wins.

Active scanning can disrupt fragile control devices and, in the worst case, affect a safety function. The safer sequence is passive network monitoring plus a physical walk-down with the people who operate the line, reconciled against vendor documentation and project files. If an active technique is genuinely necessary, schedule it inside an approved maintenance window with the process owner present and a rollback available. An inventory built from a spreadsheet nobody verified against the floor is not validated, however complete it looks.

Four categories, and the gap is almost always the fourth. Governance: who decided this, what did they decide, and who owns it now. Configuration: what is actually configured, and does it match the decision. Operations: does it keep working during normal operations, and what happened when it did not. Validation: how do you know — what did you test, when, and what was the result. Every practice guide lists specific artifacts in each category, and the evidence checklists collect them per track with a column for where yours actually lives. What evidence is sufficient is a decision for your assessor and your contract, not for a checklist.

Every practice guide displays four dates and statuses: its technical review status, its editorial review status, the date it was last reviewed, and the date the official source was last verified — plus a content version. Guides are re-verified against the official campaign and their primary sources on a rolling basis, and any guide whose technical review is still awaiting subject-matter sign-off says so on the page rather than presenting as final. If a date looks stale to you, treat the guidance as a starting point and check the primary source yourself.

By reading the primary source text and classifying the relationship by hand. No automated mapping tool is used. Each mapping records a relationship type — direct, supporting, enabling, or contextual — a confidence level, the reasoning behind it, and an explicit caveat stating what the mapping does not claim. If a caveat cannot be written honestly, the mapping is not published. Mappings are aids to your own analysis. They are not authoritative equivalence, not coverage, and not compliance determinations.

Because conflating them is the most common way a security programme overstates itself. Owning a tool is not configuring it. Configuring it is not deploying it across the scope it was meant to cover. Deployment is not operation — a control that needs manual rescue every month is not operating. And none of those is measurement or governance. The site uses one seven-level ladder across every practice guide, scorecard, and download so those distinctions stay visible and scores stay comparable.