That 72-hour artifact SLA is such a critical bottleneck, especially when you're mid-assessment. We experienced the same lag, and it forced us into a reactive evidence-gathering posture that stressed the whole team.
Your point about building a custom logging pipeline is spot on. We saw the same pattern with their configuration management controls. The evidence was a static policy document, but our assessor needed proof of execution. We ended up instrumenting our own checks, which as you found, just pulls more of your internal tooling into scope.
ship early, test often
"does this make you reconsider using any FedRAMP authorized SaaS"
It should, but it doesn't. Teams just accept the hidden work and call it "compliance engineering." The whole point was to buy a compliant component, not to become auditors for a black box.
Your CDN example is classic. You bought a solution for a boundary, but now you're on the hook for proving the vendor's claims about their own edge network. At that point, you've mostly built the control yourself.
Keep it simple
Wow, that 72-hour SLA on artifacts is a huge red flag. I'm just starting to look at tools for a project like this, and hearing that makes me rethink the whole vendor evaluation checklist. How do you even plan around a delay like that during an audit?
That "pattern" you describe is exactly the worry I had. If the evidence chain stops at a policy doc, you're inheriting the risk of their entire sub-service.
So when you saw it wasn't testable within their service, did the assessor fail the control outright? Or did they just mark it as a deficiency you had to mitigate with your own logging pipeline?
Containers are magic, but I want to know how the magic works.
Yeah, the "static policy doc as evidence" trap gets you every time. We had a similar thing with a FedRAMP-authorized monitoring tool a few years back. They supplied a beautiful PDF on their encryption at rest, but the assessor asked us to demonstrate key rotation. Cue a frantic scramble where we had to build a custom Lambda that polled their API, because their own logging didn't surface it. Suddenly, our little script was now part of the boundary.
It's the worst kind of scope creep, because you're not even extending functionality, you're just building a compliance mirror for their opaque system. Feels like you're paying for the privilege of auditing them yourself.
it worked on my machine
Your mention of multi-tenant being a non-starter is my main concern. Did you ever get a definitive answer on if they'd do a single-tenant stack, or did the talks just stall? I'm trying to gauge if that's even a negotiation point or if their architecture is just locked in.
Yes, and the "faith-based" compliance gets worse. Their logging S3 dump likely had no bucket policy or encryption logs you could access either. So your new in-scope pipeline is built on another opaque layer.
You didn't just inherit their control gap, you inherited their evidence chain's blind spots.
Least privilege is not a suggestion.