Security Classification Guides: What They Actually Are and Why People Get Them Wrong
A Security Classification Guide is a document produced by an originating authority that tells you exactly how to mark information. It spells out what can be classified, at what level, for how long, and what declassification authority applies. That sounds simple. In practice, people either ignore them completely or treat them like legal contracts when they are actually tools. Both approaches cause problems. The core purpose of an SCG is consistency. Without one, every program manager, analyst, or contractor makes their own call about whether something is Secret or Top Secret, which leads to chaotic marking and unnecessary overclassification. The guide is the single source of truth for a specific program, system, or subject area. It should answer three questions before you even open your stamp or apply a banner: What is the subject? What level? How long? Here is the part most people skip. An SCG is not a classification decision itself. It is instruction. The actual classification action happens when a trained marksman applies the guide to specific content. I spent years watching people conflate the two. They would read an SCG line and then classify everything related to that topic at that level automatically, even when the specific information didn't meet the threshold. That is overclassification, and it creates a massive declassification burden down the line.
The guide also tells you what exemptions apply. FOIA exemption handling, compartment controls, sensitive compartmented information boundaries, and derivative classification rules all live here. If your information touches any of those areas, the SCG should reference it directly. If it doesn't, that is a red flag worth investigating before you mark anything. I ran into a specific edge case a few years back that still comes to mind. We had an SCG for a weapons test program that listed classification based on yield data, range capabilities, and targeting parameters. The guide said yield figures were Secret by default unless they met a higher threshold. A contractor reading it decided that mentioning the word yield anywhere in a report required a Secret banner on the entire document. That turned a 12-page engineering summary into a fully classified artifact, even though only one paragraph contained actual yield information. The fix was straightforward but tedious. I pulled the original classification ruling from the program executive office, cross-referenced it with NISPOM section 1.5, and produced a one-page supplement that explicitly stated classification applied only to the specific data point, not the surrounding context. It took three weeks to get it approved. The workaround was adding a clear "classification by concept" versus "classification by specific reference" distinction directly into the SCG language. Most guides never do that. Derivative classification is where things get messy. You take information from an SCG and produce new documents, reports, or presentations. The rule is that your output must carry the same markings as the source, plus any additional classification triggers you introduce yourself. People routinely forget the second half. They copy content verbatim from a classified SCG, add their own analysis that crosses into a higher classification tier, and stamp it all at the lower level. That is an audit nightmare waiting to happen.
Another counter-intuitive detail that catches people off guard: SCGs have expiration dates, but most don't expire the way you think. They don't automatically declassify when the time limit runs out. Instead, the guide itself dictates when declassification occurs, and you must follow that schedule precisely. If the SCG says 10 years, that means 10 years from the date of the original classification decision on the specific information, not 10 years from the publication of the guide. I have seen programs incorrectly applying the guide publication date as the start point. That can truncate legitimate classification periods or extend them unnecessarily. Check the originator's date on every piece of information you handle, not just the guide version.
Get the Full Details
How to Use an SCG in Practice
Start by confirming the guide is current. This sounds obvious and it rarely is. SCGs get updated after program changes, policy shifts, and security reviews. Old versions circulate widely because nobody bothers to purge them from shared drives. Verify the revision date and the approving authority. If the guide references a superseded directive, toss it and find the current one. Read the classification instructions section first, then the declassification section, then the exemption and special handling notes. Most people read them backwards and miss the nuance that matters later. Pay attention to conditional language. "Classify as Secret if" means exactly that. It does not mean "always classify." The condition is the key. Identify what the condition requires and measure your information against it before making a decision. When derivative classifying, work methodically. Extract only the information you need from the source, apply the markings the guide instructs, and then evaluate any new content you added for independent classification triggers. A good habit is keeping a source log. Document what you pulled from where, what markings you applied, and why. This saves enormous time during declassification reviews and FOIA responses. Without a source log, you end up spending days re-reading documents to figure out where markings came from.
Training matters more than most organizations invest in it. You need a current derivative classification course and access to the SCG you will be using. I have watched people attempt to classify with only an onboarding briefing and a PDF they found on an intranet page. That approach produces inconsistent results and exposes the program to security review findings. Get proper training. Keep your certification current.
Common Pitfalls and Where SCGs Fall Short
SCGs are not perfect, and they fail in predictable ways. The biggest weakness is that they are often written by policy people, not operational people. The language tends toward the abstract and misses the granular detail that derivative classifiers actually need. You will see phrases like "classified as appropriate" without a concrete example. That forces every marksman to interpret the same line differently, which defeats the entire purpose of having a guide in the first place. Another structural problem is scope creep. Some SCGs try to cover an entire program's information ecosystem in a single document. The result is hundreds of pages of ambiguous guidance that no one reads end to end. People cherry-pick sections that match their immediate task and ignore everything else. A tighter, modular approach works better. Separate guides for systems, for test data, for administrative information, for contractor deliverables. Each one stays manageable and actually gets consulted. There is also the issue of dynamic classification. Some information changes classification level as circumstances evolve. A source might be Secret today and unclassified tomorrow if a declassification event occurs. The SCG should track these transitions, but many do not. When they don't, you are left guessing whether the guide's instructions still apply. The safest approach is to contact the originating classification authority directly rather than assuming the guide has been updated. Emails and formal requests create a paper trail that protects you during audits.
Not every classification decision requires an SCG. For novel topics or information types not covered by existing guidance, you need an original classification authority. Attempting to force an SCG to cover something it does not address leads to arbitrary decisions and security gaps. If the guide is silent on your specific situation, that silence itself is actionable. Escalate it. Do not fill the gap with guesswork.
Declassification and Downgrading
Declassification follows the schedule in the guide, but it is not automatic. Someone with downgrading authority must actively process the information. Bulk declassification initiatives help, but they are broad strokes. For specific files, reports, or datasets, you need targeted declassification reviews. These reviews should reference the original SCG, verify that the declassification trigger has been met, and document the action taken. Without that documentation, the information remains classified indefinitely regardless of what the guide says. The most practical tip I can offer is to build your declassification timeline at the point of creation. When you classify something, note the declassification date immediately. Store that date alongside the information. When review time comes, you already know what to process. Starting from zero during a declassification push wastes resources and creates backlogs that stretch for months or years.
