NIST 800-171 in two months, on the first try
A multi-tenant energy platform needed NIST 800-171 certification in two months to keep working with its largest customers. We rebuilt how its software was organized, deployed, and changed in AWS, then taught the team to run it without us.
certification on the first try, with no remediation requests
A distributed-energy analytics platform (name withheld)
A platform that ships a different build to every customer
The client builds a platform-as-a-service for energy analytics, using cloud analytics and machine learning to optimize how distributed energy resources connect to the grid and when they are available. Their software has helped large utilities sharpen their forecasting and power-distribution models; in one case it let a utility fold renewable sources into its capacity planning at four times the previous volume.
Their flagship application models grid interconnection, and it is customized, built, and deployed separately for each customer they serve. That per-customer model is a real strength of the product, and it was the core of the problem they brought to us. To keep working with their largest energy customers, they needed NIST 800-171 certification, and they had given themselves two months to get it. After reviewing several vendors they chose us. “We were impressed by their technical skillset, and were confident they could deliver on time,” their VP of Engineering told us.
Why certification was hard here
NIST 800-171 is largely a question of how you control and document change, and that is exactly where a multi-tenant, separately deployed product gets complicated. Every customer effectively had its own build and its own running environments, so certifying the platform meant defining one consistent, secure way to manage change across all of them rather than across a single system. The two-month target also left no room for a process that looked good on paper but slowed the developers down, since a change process nobody follows is worse than no process at all. What we needed was something auditable that the team would actually use.
What we actually did
The work came down to three things: re-architecting how the client’s accounts and customer data were organized in AWS, making each customer’s infrastructure something we could build and rebuild on demand, and defining a change-management process strict enough for NIST 800-171 without bringing development to a crawl.
We started with the account structure. Using AWS Control Tower and AWS Organizations, we built a central account to host shared services, including a centralized logging and monitoring platform, and gave each customer its own dev, test, stage, and prod environments in separate sub-accounts. Security control policies and per-customer IAM roles enforce the boundaries between them, so the structure cuts redundancy while keeping each customer’s data isolated and under the client’s control.
Inside each account, the application runs in a multi-tier, multi-AZ VPC behind an Application Load Balancer and a Web Application Firewall, with Amazon RDS for data and ECS for compute. Each VPC sits on a hub-and-spoke network joined by an AWS Transit Gateway, which lets the application use shared resources without opening a path to neighboring networks. Communication runs over TLS, all data is encrypted at rest, and Prowler runs more than a hundred security checks against the environment on an ongoing basis.
To make those environments repeatable rather than hand-built, we refactored the application to run in Docker and deploy through CloudFormation into an ECS cluster. A single set of CloudFormation templates can stand up any environment for any customer, which keeps code redundancy low and lets the team spin up a short-lived environment for a feature test, a performance measurement, a security scan, or an infrastructure change without disturbing anyone else’s work.
With that foundation in place, we defined the change-management process itself:
- Every change starts as a Jira issue, assigned to a developer and checked into an internally hosted GitLab repository.
- A peer reviews and approves the merge before the change can enter the main CI/CD pipeline.
- Jenkins orchestrates promotion through dev, then test for QA approval, then stage for end-user approval, before anything reaches production.
- Liquibase runs database migrations through AWS CodeBuild inside the target account before CloudFormation creates or updates resources.
- Smoke tests and a manual review confirm each release is sound before it goes live.
We also built a small static site, hosted in an S3 bucket in one of the client’s core accounts, that records which customer is running which version, so the team can answer that question at a glance.
None of this was handed over as a finished black box. We wrote the documentation NIST 800-171 requires and trained the client’s engineers to run the whole system themselves. “Their responsiveness is just amazing, and they proved very willing to adjust themselves to the way we worked,” their VP of Engineering said. Put less formally, we showed “a real commitment to teaching us how to fish.”
What changed
The platform passed its NIST 800-171 review on the first try, with no requests for remediation. The auditors singled out the thoroughness of the documentation as a reason the process went as quickly as it did. Beyond the certification itself, the client came away able to deploy to its customers in a more controlled and predictable way than before, and able to run and extend the system without us. “With RightBrain’s assistance, we can deploy changes to our customers in a much more reliable, predictable, and controlled fashion,” their VP of Engineering said.
The certification was the deadline. The thing that lasted was a team that no longer needed us to maintain it, which is what we look for on the way out.
Stack
AWS Control Tower · AWS Organizations · CloudFormation · ECS · Docker · Jenkins · GitLab · Liquibase · Amazon RDS · AWS Transit Gateway · Prowler