How it works
One source of truth, two outputs
BLC keeps what an authorization needs in one database, and renders it the way each audience asks for it.
One database, two deliverable tracks
FedRAMP 20x asks for machine-readable data. Rev5 packages are delivered in the FedRAMP templates. Many systems have to serve both.
BLC keeps inventory, findings, plans, POA&Ms and evidence records in one PostgreSQL database. Documents and artifacts live in git and are referenced from it. BLC is built to produce both tracks from those records, so nobody maintains a second copy.
- RecordsInventory, findings, plans, POA&Ms and evidenceOne set of records, with a change log of who changed what and when.
- OutputFedRAMP 20xMachine-readable data: key security indicator metrics, vulnerability reports, accepted vulnerabilities, incident reports and significant change notifications.
- OutputRev5The traditional package in the FedRAMP templates: SSP, SAP, SAR, POA&M, inventory workbook and monthly continuous monitoring reports.
One record, rendered two ways. A POA&M entry on the Rev5 track and an accepted vulnerability on the 20x track are the same record. A finding feeds the vulnerability report, a risk-adjustment deviation becomes an accepted vulnerability, an incident feeds the incident report, and a change request feeds the significant change notification.
Faster to an ATO
An Authorization to Operate (ATO) depends on an accurate inventory, evidence you can trace, and a clear account of what is broken and who is fixing it. BLC is built to produce those as a by-product of the work.
Inventory from authoritative sources
FedRAMP 20x treats inventory as evidence that is real-time and generated from authoritative sources, not a periodic spreadsheet. BLC is designed around that: inventory comes from the systems that know, and topology is stored as plain relational data.
PlannedBoundary, network and topology diagrams generated from that inventory.
Evidence and change history in git
Compliance documents, policies and evidence artifacts are kept in git, and the database points to them. Every change is a commit and a reviewed pull request, so the change history is the audit trail. Items such as findings and plans live in the database with a per-field change log.
One item model, with real workflows
Plans, tickets, problems and findings are views of one underlying item. Each type has a workflow that says which actions exist, who may take them, what must be attached and who must approve. Every transition is recorded with who, when and why.
800-53 control analysis alongside 20x indicators
BLC includes the NIST SP 800-53 Rev. 5 control catalog with the Low, Moderate and High baselines, and it is built to analyse controls alongside the FedRAMP 20x Key Security Indicators (KSIs). Teams that work control by control and teams that report by indicator use the same data.
Work routed by role
Each role has its own inbox: ISSO, security program manager, assessor, engineer, SOC and NOC. Approvals go to the role that owns them. The security program manager signs risk acceptance, the ISSO advises and drafts, and the assessor can read everything, including history and evidence.
Then keep it current
Getting the ATO is one milestone. See how BLC supports the monitoring that follows.