For authorizing officials and system owners
Neither a FedRAMP authorization nor a FedRAMP certification, at any impact level, and no equivalency claim. That closes any position requiring an authorized external service, and we will say so during market research rather than propose a structure around it. What remains is operating as a component inside a boundary your organisation has already authorized, under your controls, your monitoring and your signature.
An authorization is a risk decision recorded with a name on it. Not a compliance checkbox and not a technical review — an accountable person accepting that a system may operate, given what is known about it, in service of a mission that needs it.
What makes the decision hard is rarely the technology. It is that the package describing the system was assembled by people with an interest in it being approved, the assessment sampled a subset of controls, and the boundary diagram shows what somebody intended rather than what is deployed today.
So the pressure runs one way. Nobody is rewarded for an authorization that went smoothly; the asymmetry is entirely on the downside, and declining is always the safer personal choice. A vendor who does not understand that is going to keep making arguments that are irrelevant to the actual decision.
Continuous monitoring is where most of the honesty lives and where most of the attention is not. A system authorized on a package eighteen months ago has drifted, and the question of what is running today versus what was assessed is answered by a scan schedule and somebody’s diligence.
And inheritance is the most misused word in the vocabulary. Controls are inherited from a provider only where the provider actually implements them, only within the scope they were assessed in, and only where the customer implements their own half. A vendor claiming inheritance loosely is offering an authorizing official a gap with a reassuring name on it.
Where a requirement attaches to an authorized external service, a company holding no authorization is not a candidate — and no amount of security engineering changes that, because the requirement is about an authorization rather than about a security posture.
It is worth stating baldly because the alternative is a conversation in which we describe controls at somebody whose question is not about controls. Our position closes positions, and the useful thing is to establish which ones before anybody invests effort.
The route that remains is a component inside a boundary you already authorized. That is not a euphemism and it is not a workaround: it is the arrangement the authorization model contemplates for software an organisation runs itself. Your boundary, your identity provider, your logging, your continuous monitoring, your scanning, your signature. The risk you are accepting is a component inside a system you already govern.
That places obligations on us that are worth naming. A component inside your boundary has to be describable at the level your system security documentation needs — what it runs, what it reaches, what it stores, what it logs, what it requires from you. It has to be scannable by your tooling rather than exempt from it. It has to be patchable on your cadence rather than on ours. And a change to it has to be visible to your configuration management rather than arriving silently.
What we will not do is describe control inheritance we do not have. Where you inherit a control from your own infrastructure provider, that inheritance is yours and it exists whether we are present or not. Nothing about our presence extends it, and a vendor implying otherwise has given an authorizing official a false comfort in the one document where a false comfort is most expensive.
Whether we are a candidate at all — measured by a written statement of what is held and not held, checkable against the public record without contacting us.
Describability inside your system security documentation — measured by whether a component description can be written into your package without a gap marked "vendor-provided".
Scan and assessment coverage — measured by whether your own tooling can assess it as a component rather than being asked to accept a vendor report.
Patch cadence alignment — measured by whether updates follow your maintenance windows and change process rather than arriving on ours.
Change visibility to configuration management — measured by whether a change appears in your change record before it takes effect.
Drift between assessed and running — measured by whether the deployed component version is reportable at any time against what was assessed.
any authorization, any certification, any equivalency, any provisional status, any agency authorization to operate of our own, and any control inheritance. Nothing here is authorized, and inheritance you hold from your own infrastructure provider is yours and is unaffected by our presence. A statement anywhere else in our material that implies otherwise is wrong and this page governs.
Being a component means being inside your assessment rather than beside it. Your scanner reaches it, your configuration management sees its changes, your logging receives its events directly rather than through an export we perform, and your identity provider governs every account that touches it.
It also means the operational obligations are yours, and that is the honest trade. You carry the patching cadence, the monitoring, the incident response, and the assessment effort for a component in your boundary. That is more work than consuming an authorized service, and it is the only route we can offer.
Documentation is supplied at the level a package needs rather than at the level a datasheet provides: component inventory, data flows, ports and protocols, storage locations, log formats, cryptographic dependencies, and what the component requires from your environment to function.
And where a control is your responsibility inside this arrangement, that is stated explicitly rather than left implicit. A responsibility matrix that leaves a control unassigned is how a gap survives an assessment.
Authorization and certification are different words for different things and neither describes us. We hold no authorization at any impact level, and there is no certification to hold — a distinction worth stating because vendors use the second word to imply the first.
Equivalency is not a status. There is no process that confers it, and a claim to it is a claim to nothing dressed as a claim to something. We make none.
Inheritance is real and is not ours to offer. Where your infrastructure provider implements a control within an assessed scope and you implement your half, you inherit it. Our presence as a component neither extends nor diminishes that, and we will not describe your inheritance as though it were something we brought.
On assurance we can offer: an independent SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one. That is a smaller claim than an authorization and it is the accurate one. When a report exists, it will be described as what it is — an attestation with a scope and a period — rather than as a certification.
The package needs a component description precise enough that an assessor does not have to accept a vendor summary: inventory, data flows, ports and protocols, storage, cryptography, logging, and environmental dependencies. If a section of your package would have to read "as described by the vendor", that section is not finished.
The responsibility matrix is the document an authorizing official should read most carefully. Every control in scope is either yours, ours, or shared with the split stated. A control marked shared without a split is an unassigned control with a reassuring label.
An assessor should insist on scanning the component with your own tooling rather than accepting our results. We are not asking to be exempt, and a vendor asking for an exemption from your assessment has told you where to look.
And the honest cost belongs in the decision: this route is more work for your team than consuming an authorized service, because your team carries the assessment, the monitoring and the patching. That is the trade, it is stated here rather than discovered during assessment, and for some organisations it is the wrong trade.
A written determination of whether the requirement attaches to an authorized external service or to a component inside your boundary — answered before any assessment effort is spent.
That determination is the whole first step and it is free. If the requirement attaches externally, we are not a candidate and the correct outcome is that the conversation ends there rather than after a package has been started.
If the component route is available, the next artefact is the responsibility matrix rather than a demonstration. An authorizing official can read it in an afternoon and can tell from it whether this is a decision they would sign.
Only after that does a bounded scope make sense — and the observation phase this architecture recommends everywhere typically requires read-only access, which is the smallest possible thing to authorize.
No. Not at any impact level, and there is no certification to hold either — those are different words and we will not use the second to imply the first. We claim no equivalency, because no process confers it. This closes any position requiring an authorized external service, and we would rather you had that in market research than in an assessment. The route that remains is a component inside a boundary you already authorized, where the signature and the risk posture are yours.
No. Inheritance flows from a provider that implements a control within an assessed scope, to a customer that implements their half. Where you hold inheritance from your own infrastructure provider, it is yours and our presence neither extends nor diminishes it. A vendor describing your inheritance as something they bring is putting a comfortable word over a gap, in the one document where that is most expensive. Every control in scope appears in the responsibility matrix as yours, ours, or shared with the split written out.
It is, and that belongs in your decision rather than in a footnote. Your team carries the assessment, the scanning, the monitoring and the patch cadence for a component in your boundary. For some organisations that is the wrong trade and the right answer is to buy an authorized service instead — we will say so. What you get for the extra work is that the component is inside your assessment rather than beside it, which is a different and in some ways stronger position than accepting somebody else’s package.
By being able to ask at any time and by seeing changes before they take effect. The deployed version is reportable on demand against what was assessed, and a change enters your configuration management record rather than arriving silently. That is the property that fails first in most arrangements, so it is worth testing during the assessment rather than accepting as a statement — ask for a version report, then ask for one again after a change, and see whether the change appeared in your record first.
Then that resistance is the finding. We are asking to be assessed as a component, which means your tooling reaches it and your assessor forms their own view rather than reading ours. A vendor seeking an exemption from your scanning has told you where the weakness is, and an authorizing official is right to treat the request itself as evidence.