Government fuel contracts, control by control.
If your FBO holds a DLA into-plane contract, someone will ask how your software handles CMMC. This page is the answer. All 17 CMMC Level 1 practices, what RampRelay does about each one, and which parts stay with you. The parts we do not claim are here too.
Two frameworks get confused. Only one is likely yours.
FedRAMP applies to cloud services a federal agency buys and runs on. CMMC applies to defence contractors and comes down through your contract. An FBO fuelling government aircraft is a contractor, not an agency, so the question is almost always CMMC. One clause decides which level.
FAR 52.204-21 only
Federal Contract Information · CMMC Level 1
Your contract creates information that is not public but is not sensitive: what you fuelled, when, how much, and what you billed. Fifteen basic safeguarding requirements, written up as 17 practices. You self-assess once a year. No auditor, no certificate.
This page is written to be most of your evidence for that assessment.
DFARS 252.204-7012
Controlled Unclassified Information · CMMC Level 2
Your contract puts genuinely sensitive government information in your hands. That means 110 controls from NIST SP 800-171, a score filed with the government, and an outside assessment every three years. Any cloud service holding that information has to meet a FedRAMP Moderate equivalent standard.
RampRelay is not that system, and we will say so plainly. Scope it out instead: see below.
Not sure which one you are under? The clause list in your contract settles it in about five minutes. Send it over and we will read it with you.
All 17 practices, none skipped.
Every Level 1 requirement is below, across all six domains. Each row gives the identifier, the requirement in plain language, what RampRelay does about it, and who owns it. Nothing is marked as ours that is really yours, and nothing is left out.
Both the counts and the identifiers get queried, so: CMMC Level 1 is 15 requirements, one per paragraph of FAR 52.204-21(b)(1), and 17 practices, because the malicious-code paragraph (xv) carries three of them. That is why SI shows FAR (b)(1)(xv) three times below. CMMC 2.0 also renumbered the identifiers to follow the FAR paragraphs, so AC.L1-3.1.1 became AC.L1-b.1.i. The current identifier leads on each row and the old one sits beneath it, because plenty of questionnaires still quote the old form.
Access Control
4 practicesLimit system access to authorised users, to processes acting on behalf of those users, and to devices.
Every page outside the public order form needs an account. Access is scoped by membership: your staff see your FBO, your customers see only their own account, and nothing crosses. The check runs before the page does, so a link belonging to another operator returns a 404.
Limit system access to the types of transactions and functions that authorised users are permitted to execute.
Access is granted by permission, not by job title. Three staff roles (Admin, Manager, Line crew) and five customer portal roles, all gated on named permissions held in one registry. Line crew can be limited to named airports. The full permission matrix is a live page inside the product, so you can show an assessor the setup itself instead of a claim about it.
Verify and control or limit connections to, and use of, external systems.
The outbound connections are a short, documented list: email, SMS, accounting sync and card processing. Each one is off until you connect it, uses credentials issued to your account alone, and can be disconnected by you at any time. Stored third-party secrets get a second layer of encryption on top of the database's own. The devices and networks your staff connect from stay yours to control.
Control information posted or processed on publicly accessible information systems.
What is public is a setting you choose, never a side effect. Each location is public, account holders only, or neither, and a new location starts not public. Nothing reaches the open internet until you publish it. Pilot status links use an unguessable per-order token, and those tokens are stripped out of any stored copy of a message.
Identification and Authentication
2 practicesIdentify information system users, processes acting on behalf of users, and devices.
Every account is one named person with their own email address. No role needs a shared login: line crew get their own scoped accounts, so the audit trail names a person, not a terminal. Machine access is a named API key tied to one account, stored hashed, and revoked on its own. Not handing out shared logins is the part that stays with you.
Authenticate or verify the identities of users, processes or devices as a prerequisite to allowing access.
Sign in by password, emailed one-time code, or your own Google or Microsoft account. Passwords are checked for length, common passwords, all-numeric values and similarity to the user's own details, and are stored only as salted hashes. Multi-factor authentication is available on any account and required for our own administrative access. Sessions use secure, HTTP-only cookies over HTTPS. Sign-in is rate limited and will not tell an attacker whether an address exists.
Media Protection
1 practiceSanitise or destroy information system media containing Federal Contract Information before disposal or release for reuse.
RampRelay writes nothing to removable media and needs no printing. Fuel tickets, invoices and receipts can stay on screen, which shrinks this control rather than meeting it. Stored data sits in a managed database and file store, and the provider wipes media on decommission under its own audited programme. What is left in scope is the paper and the laptops in your own building.
Physical Protection
4 practicesLimit physical access to information systems, equipment and the respective operating environments to authorised individuals.
No RampRelay server, appliance or drive sits in your building. Data-centre access control comes from the hosting provider's audited physical security programme. Your front-desk terminals and ramp tablets stay yours to control.
Escort visitors and monitor visitor activity.
This one is about people walking into your building. It is yours in full and the software you run makes no difference to it. The hosting provider runs the same programme at the data centre.
Maintain audit logs of physical access.
Data-centre entry logging comes from the hosting provider. Logging who was behind your counter is yours. RampRelay does keep a full record of who did what inside the software, but that is a different control, covered above.
Control and manage physical access devices.
Keys, badges and door codes at your FBO. RampRelay issues no physical credential of any kind, so it adds nothing to this inventory.
System and Communications Protection
2 practicesMonitor, control and protect organisational communications at the external boundaries and key internal boundaries of the information system.
All traffic is HTTPS. Plain HTTP is redirected, and strict transport security is set to a year, covers subdomains and is preloaded, so a browser will not send an unencrypted request in the first place. Traffic passes a CDN and web application firewall before it reaches the application. Public token links are rate limited and public forms carry bot checks. Data at rest is encrypted by the database and file store, with a second layer of encryption over stored credentials.
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
The web tier is the only part with a public address. The database, cache and background workers sit on a private network and cannot be reached from the internet at all. There is no jump box and no open management port. Our administrative access uses the same signed-in, MFA-protected path as everything else.
System and Information Integrity
4 practicesIdentify, report and correct information and information system flaws in a timely manner.
Dependency monitoring runs all the time and raises patch requests on a schedule. New versions are held for a few days first, so a bad release that gets pulled never reaches us. Every change has to pass automated checks before it ships: linting, the full test suite, a database migration check and a production security-configuration check. Errors in the running system raise an alert. We deploy continuously, so a fix reaches you in hours rather than on a release calendar.
Provide protection from malicious code at appropriate locations within the information system.
No customer-supplied code runs anywhere in RampRelay. Uploads are limited to documents and images, are kept in file storage rather than on the application server, and are served from a separate domain where nothing can execute. Servers are rebuilt on every deploy from a locked list of dependencies, so a running server never drifts from what was reviewed. Anti-malware on your own workstations stays yours.
Update malicious code protection mechanisms when new releases are available.
There is no signature file on a server here to go stale. Every dependency RampRelay uses is checked against the global vulnerability database as new advisories are published, and a fix is raised automatically. Base images and dependencies are pulled again on each deploy, and the services underneath are patched by the host. No long-lived server sits there with an out-of-date scanner on it.
Perform periodic scans of the information system and real-time scans of files from external sources as files are downloaded, opened or executed.
Scanning is continuous, not periodic. Every dependency is re-checked against published advisories as they land, and every proposed change is scanned again before it can ship. Files arriving from outside are stored where nothing can run them. Scanning files your staff download onto their own machines is anti-malware on your side, which RampRelay does not replace.
Where the data lives
The RampRelay application, its database and its file storage all run in a United States region. Backups stay in the same country. Ask us for the current list of third parties involved in running the service and what each one sees. It is written for your vendor review.
Audited infrastructure, evidence you can file
RampRelay is hosted on Render, and Render states its own certifications on its compliance page, where your assessor can verify them at the source. Those cover the hosting layer this page inherits: the physical controls in the PE domain, network separation, and media handling on decommission. The audit report behind them is issued under Render's own NDA and is not ours to forward, so if your assessor needs the report itself, tell us and we will open that request with Render for you.
The rest of our security postureWhat we do not claim.
A compliance page that only lists wins is no use to you. Here are the boundaries, stated before you ask, so nothing turns up late in a procurement review.
RampRelay is not CMMC certified, and no software can be.
CMMC assesses an organisation and the boundary it draws, not a product. What a vendor can honestly offer is a control-by-control mapping like this one, plus a written statement your assessor can rely on. Be wary of any vendor selling a certified product.
RampRelay is not FedRAMP authorised.
FedRAMP applies to cloud services a federal agency itself buys and operates on. If the government is your customer rather than your user, FedRAMP is generally not the framework that applies to you. CMMC is.
RampRelay is not built to hold Controlled Unclassified Information.
It is built for commercial FBO work: orders, fuel, inventory and invoices. If your contract carries DFARS 252.204-7012, keep CUI out of RampRelay altogether rather than treating it as a CUI enclave. See the scoping note below.
No export-controlled technical data, and no attestation of our own.
RampRelay holds no ITAR or EAR technical data by design. The infrastructure underneath it is independently audited and we can hand you those reports, but RampRelay itself does not yet hold a SOC 2 report covering the application and the company around it. An assessor will care about that difference, so we point it out ourselves rather than let the hosting certificates blur it.
Three steps, in this order.
Find out which clause you are actually under
Find the safeguarding clause in your DLA contract. FAR 52.204-21 on its own means Federal Contract Information and CMMC Level 1: a self-assessment against the 17 practices above. DFARS 252.204-7012 means Controlled Unclassified Information and CMMC Level 2: 110 controls and an outside assessment. Everything else follows from that one answer, and the two get mixed up all the time.
Keep the boundary small on purpose
Government reporting belongs in the government's own portal. RampRelay holds your commercial operating data and, at most, transaction records at Federal Contract Information level: date, tail, product, quantity, price. A small, clearly drawn boundary is easier to assess, cheaper to keep up, and much easier to defend than one that grew on its own.
Get it in writing for your assessment file
We will sign a statement of the mapping above for your file, fill in your security questionnaire, and take your assessor's questions directly instead of through your team. Send us the clause and the questionnaire and we will work from those.
Send us the clause.
Book a demo and bring the safeguarding clause from your DLA contract, or your customer's security questionnaire. We will tell you which level applies, what we can sign, and where the limits are before you commit to anything.
This page describes how the RampRelay platform maps to the basic safeguarding requirements of FAR 52.204-21. It is provided to support your own assessment. It is not legal advice, not a certification, and not a substitute for defining and assessing your own system boundary. Last reviewed 18 August 2026.