Running NIST SP 800–53 Controls on a Team That Fits in a Conference Room

How a small SaaS company built a full NIST compliance program without a security department.

—

Most people in infosec assume that NIST SP 800–53 is a framework for big organizations. The kind with a CISO, a SOC team, a few GRC analysts, and a compliance coordinator. Small companies, the thinking goes, should stick to something lighter and leave the heavy frameworks to the people with headcount.

We’re a small software company. Everyone fits in a conference room. And we run a full 800–53 Rev 5 compliance program across twenty control families, mapped to NIST CSF 2.0, CIS Controls v8.1, TX-RAMP High, HECVAT, and a few other frameworks that our customers ask about. Here’s how that works in practice, and what we’ve learned doing it for the past few years.

—

Why 800–53 in the First Place?

We build software for higher education institutions. Many of them are state-funded, subject to FERPA, covered by state student data privacy laws, and increasingly required to use vendors that meet state-level cybersecurity authorization programs like TX-RAMP. We didn’t get to pick the easiest framework. Our customers’ compliance requirements picked for us.

We needed a single documentation baseline that could hold up against a security questionnaire from a community college in Texas, a state university system running its own vendor risk management program, a Canadian institution subject to PIPEDA, and a UK institution operating under UK GDPR.

800–53 Rev 5 turned out to be the right foundation for this, mostly because it’s comprehensive enough that nearly every other framework maps into it. If you write your policies against 800–53 controls, you can crosswalk to CIS, SOC 2, CMMC, HECVAT, and most state-specific requirements without starting from scratch each time.

The tradeoff is volume. 800–53 defines over a thousand individual controls. The real question for a small team isn’t whether you can implement all of them, but how you implement the ones that matter or are mandatory, document them honestly, and build a program that actually makes your systems more secure instead of just generating paperwork.

—

Everyone Wears Six Hats

In a large organization, NIST’s role-based model maps cleanly to an org chart. You’ve got an Authorizing Official, an Information Security Manager, an ISSO, a System Administrator, a Privacy Officer. Different people, different meetings, clean lines of responsibility.

On our team, one person holds the titles of Information Owner, Authorizing Official Designated Representative, Information Security Manager, IT Manager, and ISSO. Another person is simultaneously the CEO, President, Authorizing Official, and Information Owner. The person who writes the access control policy is the same person who reviews the audit logs and responds to incidents.

We document all of this explicitly. We maintain an Information Security Roles and Responsibilities matrix that lists every information system we operate, from our Active Directory domain to our AWS IAM environment to the Slack workspace, and names the specific individuals who fill each security role. When one person holds six roles, that goes on paper. The auditor can see exactly who’s responsible for what, and just as important, so can we.

What a lot of people don’t realize is that NIST doesn’t require each role to be a different person. It requires that roles be defined, responsibilities be assigned, and assignments be documented. Separation of duties matters, and we enforce it where it counts, particularly around access provisioning and audit review. But the framework is more flexible about organizational structure than most people assume.

—

Two Documents Per Control Family, Every Time

Early on we made a decision that saved us enormous rework later: every NIST control family gets at least two documents. A policy and a procedure.

- RSP-AC01: Access Control Policy
- RSP-AC02: Access Control Procedures
- RSP-AU01: Audit & Accountability Policy
- RSP-AU02: Audit & Accountability Procedures

This pattern repeats across all twenty families. The policy covers what we do and why. The procedure covers how, with specific steps, system names, and responsible parties.

Every document follows the same structure: 
- Introduction
- Purpose
- Scope
- Related Documents
- Roles and Responsibilities
- Management Commitment
- Authority
- Compliance
- Exceptions
- Policy Review Maintenance
- Family-specific Requirements
- Compliance Crosswalk

We did this on purpose. When an auditor picks up any document in our library, they already know where to find the enforcement clause, the review cadence, and the exception process. When we needed to update the authority section across the entire library after adding CMMC 2.0 to our framework alignment, we could do it systematically instead of hunting through twenty different document layouts.

Beyond the policy/procedure pairs, we keep a small set of cross-cutting documents:

- Access Control: Information Security Roles and Responsibilities (the master mapping for every system)
- Contingency Planning: Data Backup Policy (maps each information system to a specific backup strategy, all following the 3–2–1 rule)
- Auxiliary: Applicable Security and Privacy Laws (one authoritative reference for every law, regulation, and compliance obligation we’re subject to)
- System Security Plan (SSP): The comprehensive document that ties everything together

Each policy’s Related Documents section cross-references the other policies it depends on. The incident response policy points to the contingency planning procedures. The backup policy references access control, audit, incident response, media protection, and encryption policies. Everything links to everything else, which matters when you’re trying to demonstrate a coherent program rather than a stack of disconnected documents.

—

Where Automation Helps, and Where It Doesn’t

Small teams have one real advantage here that doesn’t get enough credit: short feedback loops.

When our audit policy says we review system audit records at least weekly for signs of unusual activity (account misuse, privileged access anomalies, suspicious database queries), that review actually happens. It doesn’t get delegated through three layers of management to a junior analyst who triages findings into a ticketing queue. The person reviewing the logs is the person who built the system, knows what normal looks like, and can act on what they find immediately.

We automate the mechanical stuff:

Vulnerability scanning runs monthly against operating systems, infrastructure, web applications, and databases. An independent assessor handles additional annual scans. High-risk findings get a 30-day remediation window, moderate gets 90 days, low gets 180. These aren’t aspirational targets we pulled from a template. They’re the SLAs we actually hold ourselves to, and the ones our auditors verify.

Audit log generation is baked into every layer. Our web applications log administrator activity, authentication events, authorization checks, data access, data modifications, and permission changes. Every record captures the event type, timestamp, source, outcome, and user identity. We synchronize time to NIST servers so everything correlates properly.

Backup testing follows documented procedures per system. We don’t just confirm that backups ran successfully; we test restores. Full data restorations, integrity validation, application recovery scenarios. The backup policy names specific systems (our CORDERNET domain controllers, TracCloud RDS instances, AWS IAM configurations) and defines the backup strategy, retention period, and responsible party for each one.

Configuration management baselines are documented and maintained. Changes follow a defined process. We know what our systems should look like and can tell when something drifts.

The parts that can’t be automated are the judgment calls. Is this audit finding a real positive or a known false positive in our environment? Do we accept this residual risk or remediate it? How do we prioritize when two things need attention at the same time? A small team makes those calls faster and with more context, because the person deciding already has the full picture.

—

Training at a Company Where Everyone Already Gets It

Security awareness training is a NIST requirement, and it feels a little awkward when your whole team fits in one room. Putting everyone through a generic phishing awareness module can seem like going through the motions.

We still do it. Our policy requires security awareness training for all personnel before they get access to information systems, then annually after that. We also do role-based training: anyone with incident response responsibilities gets IR-specific training within six weeks of taking on that role, plus practical exercises that go beyond clicking through slides.

But honestly, the real training happens in the daily work. When your configuration management policy requires changes to be reviewed and least privilege to be enforced, and the same three people are both the authors of those policies and the ones subject to them, the learning is continuous. You internalize the controls because you live inside them every day.

That said, don’t skip the formal training just because your team already knows the material. Your auditor needs to see documented completion records. And even experienced people benefit from the annual refresh. The threat landscape shifts, new regulations go into effect, and the training cadence creates a natural forcing function to update everyone’s knowledge.

—

The Compliance Calendar

A compliance program doesn’t have an end date. It’s a set of recurring obligations, and for a small team, the most important thing is knowing exactly what’s due and when.

Our calendar breaks down like this:

- Weekly: Audit log review and analysis
- Monthly: Vulnerability scans, backup verification
- Quarterly: Access privilege reviews, account cleanup
- Annually: Procedure reviews, incident response testing (per NIST SP 800–61), security awareness training, independent security assessments, risk assessment reviews, backup restoration testing
- Every three years: Full policy reviews, comprehensive independent risk assessments

The policies themselves bake in these cadences. The Incident Response Policy gets reviewed every three years; its procedures get reviewed annually. Configuration Management follows the same pattern. This isn’t arbitrary. It’s the NIST-recommended rhythm, and it balances the need for keeping things current against the reality that a small team can’t spend every quarter rewriting policies.

We also bring in an independent external auditor annually. Findings get remediated according to their recommendations. This part is non-negotiable. You can’t grade your own work, and on a team this small, everyone has a natural conflict of interest with everything that everyone else does.

—

Dealing with Dozens of Overlapping Regulations

If you’re a SaaS company serving institutions across multiple jurisdictions, you’re not just implementing 800–53. You’re also subject to FERPA for student records, COPPA for minors’ data, state consumer privacy laws like CCPA/CPRA and TDPSA, student-specific data protection statutes across dozens of states, and potentially UK GDPR and Canada’s PIPEDA depending on where your customers are.

We handle this with a single document that catalogs every applicable law, regulation, and compliance obligation, including the citation, effective date, scope, enforcement mechanism, and specific requirements. Every policy in our library points back to this one reference instead of trying to list applicable laws inline.

The payoff shows up whenever a new state passes a student data privacy law (which happens regularly). We update one document instead of twenty. And because the policies are already written to meet or exceed the strictest applicable standard, adding a new regulation is usually a matter of confirming coverage rather than overhauling controls.

—

A Note on the “How Do I Get Compliant in Six Months?” Posts

Every few weeks on r/sysadmin or r/compliance, someone posts a version of the same question: “I’m a solo IT guy and my boss wants us SOC 2 compliant by Q3, where do I start?” Or it’s 800–53, or CMMC, or ISO 27001. The framework changes but the situation is always the same. One person, no existing program, an aggressive deadline, and a vague sense that there must be a checklist somewhere that makes this tractable.

I get the impulse. But the honest answer is that you can’t do it in six months, and framing it as a six-month project is part of the problem.

Compliance at the level these frameworks demand isn’t a deliverable you finish and hand off. It’s an operating model. You’re not writing documents and then moving on. You’re committing to weekly audit log reviews for the rest of time. Monthly vulnerability scans. Annual incident response tests. Triennial risk assessments. Ongoing training records. Continuous evidence collection. The initial documentation push is maybe 30% of the work. The other 70% is the indefinite operational commitment that comes after.

When we stood up our 800–53 program, the initial policy and procedure development took the better part of a year, and that was with someone who already understood the framework doing most of the writing. The first external audit surfaced gaps we hadn’t anticipated. The second year was tighter. By year three we had a rhythm. But at no point was there a finish line where we could say “done” and stop thinking about it.

If your boss wants a compliance program and you’re the only person who’s going to build and run it, the most important conversation isn’t about which GRC tool to buy or which template library to download. It’s about whether the organization understands that this is a permanent operational commitment, that it will consume a meaningful percentage of someone’s time forever, and that the timeline for a credible program (not a paper exercise, a real one) is measured in years, not quarters.

That’s not meant to be discouraging. A small team can absolutely do this, and this entire post is evidence of that. But going in with the expectation that you’ll knock it out in a sprint is how you end up with a pile of policies that don’t reflect reality and an auditor who can see right through them.

—

Advice for Other Small Teams

Do the risk assessment first. Before you write a single policy, understand what you’re protecting, what the threats are, and what happens if something goes wrong. The risk assessment shapes everything downstream. Without it, you’re writing policies that don’t connect to anything real.

Map to multiple frameworks from the start. If you know your customers will send you SOC 2, CIS, CMMC, or HECVAT questionnaires, build those crosswalks into your document structure on day one. Going back and retrofitting framework mappings onto existing documentation is miserable work.

Write down the role assignments, even when they look redundant. It feels silly documenting that the same person serves as Information Owner, ISSO, and IT Manager. Do it anyway. When your team grows, or when you need to explain your organizational structure to an auditor or a prospective customer, you’ll be glad you have it on paper.

Spend time on the procedures, not just the policies. Policies are relatively straightforward to write. Procedures, the step-by-step instructions for how controls are actually implemented, are where the real effort goes. A policy that says “we test backups” means nothing without a procedure that specifies which system, which data, which method, how often, and who checks the results.

Close the gap between paper and practice. The biggest advantage a small team has is that there doesn’t need to be any distance between what your policies say and what actually happens. At large organizations, policies tend to be aspirational and implementation is uneven. At a small company, if the policy says you review audit logs weekly, you either do it or you don’t, and everyone knows which one it is. That transparency is valuable. Build controls that genuinely improve security, not controls that just read well.

Wear the hats, but don’t cut corners. NIST doesn’t care how many people are on your team. It cares that the right things get done, that there’s documentation, and that someone is on the hook. A team that fits in a conference room can deliver on all of that just as well as a department of fifty, and sometimes better, because the accountability is personal.

Be honest about where you are. There’s a tendency in this space to write policies and SSPs that paint a perfect picture. Everything is fully implemented, every control is satisfied, every process runs like clockwork. You read some companies’ documentation and it sounds like they’ve never had a gap, never missed a scan, never had to make a tradeoff between what NIST recommends and what they can actually sustain this quarter.

That’s not real, and auditors know it. More importantly, it traps you. If your documentation says you’re doing something you’re not actually doing, you now have two problems: the original gap and the dishonesty on top of it. And you’ll spend more energy maintaining the fiction than it would have taken to just fix the gap. And that’s not to mention legal liability!

What actually works better is documenting your program honestly, including the parts that are still maturing. If a control is partially implemented, say so, and write down what you’re doing about it and when you expect to close the gap. If you had to make a risk-based decision to deprioritize something, document the rationale. If your incident response testing last year was a tabletop exercise instead of a full simulation, that’s fine, write it down and plan to level up next year.

An auditor who sees honest documentation with a clear improvement trajectory is going to give you a lot more credit than one who sees a pristine paper program that falls apart under questioning. And beyond the audits, there’s something to be said for just being able to sleep at night. When your documentation reflects what’s actually happening, you’re not carrying around the mental weight of knowing there’s a gap between the story and the reality. You can look at your program, see where it stands, and know that whatever it is, it’s real. That peace of mind is worth more than a clean-looking control matrix that you know is aspirational.

The only compliance program worth having is one you can stand behind honestly. Build that, and the rest follows.

—

Wrapping Up

800–53 wasn’t designed for small companies, but small companies can absolutely implement it well. The controls themselves don’t change based on your headcount. What changes is how you organize, how much you automate, how you divide the work, and how fast you make decisions.

If your customers need it, if your data justifies it, or if you want the most thorough security baseline available, don’t let the size of your team be the reason you don’t try. Get the risk assessment right. Build a clean, repeatable document structure. Automate the things that should be automated. Make the judgment calls yourself. And above all, be honest about whether your team is actually doing what your policies say you’re doing.

On a team this small, that honesty comes naturally. And that’s probably the biggest thing working in your favor.