Role Separation in Single-Developer Systems: Enforcing AC-5 Without a Team

NIST 800-53 AC-5 — Separation of Duties — gets treated like a headcount requirement. The assumption is that you need multiple people to prevent any single individual from having unchecked control over a system. That assumption is wrong, and it disadvantages small vendors who often have the tightest, most auditable delivery pipelines in the market.

The intent of AC-5 is not to require a team. The intent is to prevent unilateral, unreviewed, and untraceable change — especially in production. A single developer can meet that intent if the delivery system is designed to enforce it. This white paper explains how, and what the evaluator-ready evidence package looks like.

What AC-5 Actually Requires

NIST 800-53 AC-5 requires that organizations: separate duties of individuals as necessary to prevent malicious activity without collusion, document separation of duties, and implement separation of duties through assigned information system access authorizations.

The operative phrase is 'as necessary to prevent malicious activity without collusion.' This is a risk-based standard, not a headcount standard. The control asks whether the system has been designed so that no single action — even by an authorized user — can compromise the system without leaving a detectable trace. That is achievable without a team.

The Solo Developer Risk Model

The risk AC-5 is designed to mitigate is insider threat: a single actor making unauthorized, unreviewed, or undocumented changes that compromise system integrity. In a single-developer system, the threat model is different from a large organization — there's no insider collusion risk — but the risk of unreviewed, untraceable change is real.

The mitigation isn't additional personnel. It's pipeline design that enforces review gates, generates evidence, and makes every change attributable and auditable. The question isn't 'how many people touched this?' It's 'can you prove what changed, when, why, and that it was validated before it reached production?'

The Five Controls That Meet AC-5 Intent for Solo Systems

1. No direct-to-production deployments. Production changes only flow through CI/CD. No manual pushes, no hotfixes that bypass the pipeline. Every change is committed, reviewed (even self-reviewed with a documented rationale), and deployed through the same controlled path. Evidence: deployment logs showing all production changes originated from pipeline runs, not direct access.

2. Gated releases. Before any build reaches production, it must pass: automated tests, dependency security scans, required version tagging, and a release checklist. Failed gates stop the deploy. Evidence: build logs showing gate results for every release.

3. Signed artifacts. Every release artifact is hashed and signed. The hash is recorded at build time and verified at deploy time. If anything changed between build and deploy, the signature fails. Evidence: artifact provenance log with hashes and timestamps.

4. Immutable audit logs. Key system events — authentication, access, configuration changes, deployments — are logged to a tamper-evident store. Logs are not modifiable by application-level access. Evidence: log integrity verification and retention records.

5. Break-glass path with review. For genuine emergencies requiring a bypass, a documented break-glass procedure exists: the bypass is logged with a reason code, the change is reviewed post-incident, and the review is documented. Evidence: break-glass event log with post-incident review records.

What the Evidence Package Looks Like

An evaluator assessing AC-5 compliance for a single-developer system should ask for — and a well-prepared vendor should be able to produce — the following artifacts for the last 10 production releases: build logs (what ran, what passed, what failed), test results (automated test suite outcomes), security scan results (dependency audit, vulnerability findings and dispositions), deployment records (who triggered, when, from what commit), artifact hashes (build-time and deploy-time, with verification), and any break-glass events with post-incident reviews.

If a vendor can produce this package cleanly for 10 consecutive releases, they have demonstrated operational AC-5 compliance — regardless of team size.

For Evaluators: Questions to Ask Any Vendor

Can you produce deployment logs for the last 10 production releases? Do all production changes flow through CI/CD, or are direct-to-production changes possible? How are release artifacts signed and verified? What events are logged, and how is log integrity protected? What is your break-glass procedure, and when was it last used?

A vendor who can answer these with artifacts — not assertions — has met the intent of AC-5 regardless of team size.

---

⚠️ Disclaimer: This content is provided for informational purposes only and reflects the independent analysis of BlueVioletApps LLC. It does not represent the views, policies, or positions of the U.S. Navy, Department of Defense, or any federal agency. BlueVioletApps LLC is an independent, veteran-owned software company and is not affiliated with, endorsed by, or operating on behalf of any government agency. All product and company names mentioned are the trademarks of their respective holders.