Breaking: Just saw NordLayer is now SOC 2 certified. Anyone have the report?

Yeah, it definitely smooths out the procurement side of things for us too.

I haven't gotten the full report yet, but I did ask our NordLayer rep last week. They provided a standard SOC 2 Type II executive summary letter immediately. Getting the actual detailed report required signing an NDA, which is pretty typical. They said the audit scope covered their core global infrastructure and management plane, no major carve-outs that they highlighted.

Might be worth just asking your contact directly. If you do get it, I'd be curious how they handle key rotation cycles.

The NDA requirement is standard, but the real value is in the detailed controls. We always look for the testing procedures and sample sizes in the full report, not just the scope statement. A clean summary letter is a good sign, but it doesn't tell you about the auditor's sample selection methodology.

On the key rotation point, that's a solid question. It's often a place where the 'management plane' scope gets tested. If you get the report, check the specific control criteria around cryptographic key management (CC6.1 usually) and see what the sample period and frequency was. I'd be interested if their cycle aligns with common cloud provider standards or if they've enforced a stricter internal policy.

Agreed on it being a key checkbox for regulated industries. One caveat based on our own vendor reviews is that a SOC 2 Type II for a 'product' can sometimes have a narrower scope than you assume if their certification is for a specific service tier or geographic region. The request for the detailed report is the right step.

While user1213's note about the NDA is accurate, I'd push to specifically request the auditor's opinion letter and the detailed testing matrices from the full report, not just the service organization's description. The opinion letter will state if the description is fairly presented, which is critical.

For your migration plan, I'd correlate the report's in-scope systems list against the specific NordLayer features you intend to adopt. A clean report on their core infrastructure is good, but if you're using a beta feature or a specific gateway region, you need to confirm it's included in the audit boundary.

You've hit on a critical procedural point. Requesting the auditor's opinion letter is indeed the key action, as the service organization's description is just one piece. The opinion letter's statement on whether that description is "fairly presented" is the auditor's stamp on its accuracy. Without it, you're trusting the vendor's self-disclosure.

A practical step I've taken in similar reviews is to map the report's "systems in scope" list directly to the vendor's published architecture diagrams or API endpoint documentation. This often reveals if ancillary systems, like a specific admin console API or a regional logging service, are explicitly included or exist outside the audit boundary. This mapping exercise is especially important for a service like NordLayer, where global gateway diversity is a selling point.

Totally agree on checking the scope against the features you'll actually use. We ran into that with another vendor - their core API was covered, but the admin portal we needed daily wasn't in the audit boundary.

The tip about requesting the opinion letter is key. It's the auditor's actual stamp, not just the vendor's summary. Makes the security review go much smoother.

Did your team end up doing that mapping exercise against their architecture docs? I'm curious if they clearly list the 'systems in scope' in a way that's easy to cross-reference.

Spot on about sample size being critical. A report can pass with a tiny sample that doesn't reflect real-world volume or edge cases. Always check the sample dates too. If they only tested from a quiet period, it's a red flag.

For CC6.1, cloud provider standards are often the bare minimum. I'd want to see a policy tighter than, say, AWS KMS defaults.

Absolutely, the sample period is a huge part of the audit's credibility. I've seen reports where the testing window conveniently avoided major release cycles or planned maintenance events. It's worth asking if their sample includes a key rotation event, or if that's just attested by policy.

On the key point, I'd also check who holds the root keys. If they're using a cloud KMS but managing their own root keys in it, that's a very different control posture than using the cloud's default, managed keys. The report should detail that separation.

Great point on the root keys. I'd also ask if their cloud KMS logs are included in the audit scope, or if that's a separate layer. The separation matters, but the audit trail around key access does too.

Sample periods are huge. For a service like this, I'd specifically ask if their testing window included a major feature deployment or a gateway failover event. That's the real stress test.

Yep, the mapping step is crucial. We did it with our last vendor and it got messy because their 'in-scope' list used internal system names that didn't match their public docs at all. Had to ask for a crosswalk.

Good call on the opinion letter. That's the only way to validate the vendor's own description is accurate. Makes the whole 'systems in scope' list actually meaningful.

Curious if you've seen vendors that proactively include that mapping in an appendix? That would save so much time.

Yeah, that checkbox makes procurement happy. It's the details that'll bite you.

The report is usually a heavily negotiated document. Even when you get it, the "in scope" list is often written in vendor-speak that doesn't map cleanly to their public components. I'd bet their gateways are covered, but what about the admin API your team will actually hit daily?

Don't let the cert be the final step. It just means you can start asking the hard questions.

That mapping exercise sounds like a lifesaver, honestly. I've been in meetings where someone just holds up the SOC 2 logo on a slide and everyone nods, and this is exactly why that's scary.

> map the report's "systems in scope" list directly to the vendor's published architecture diagrams

I've tried something similar but got lost in the jargon. Their public docs will have a slick diagram with "Secure Gateway" boxes, but the report says "SG-DBR-Prod-02" and you have no idea if that's the same thing. Is it common for vendors to push back if you ask for a simple cross-reference between the two? Like, is that seen as asking for too much?

Yeah, that crosswalk request is totally reasonable. The good vendors I've worked with include a simple glossary or mapping table in an appendix, exactly for this reason. It shouldn't be a secret decoder ring.

I've also seen some reports where the auditor adds a note saying something like "the system described as 'Core Platform' in public documentation corresponds to services XYZ-PROD-1 through 3 in the scope." Makes everyone's life easier.

If they push back on providing that mapping, it's a yellow flag for me. It suggests they might not be fully comfortable with how the audit boundary was drawn.

Exactly. That auditor's sampling methodology is what separates a real test from a compliance theater script. I've pulled reports where the sample was five items, all from a single quiet Tuesday, and they called it a quarter.

On key cycles, checking if they just meet the cloud default is the bare minimum. You need to see if the auditor actually verified a rotation event happened during the period. I've seen reports where the control is satisfied by a policy document stating annual rotation, but the sample period was only three months long, so it was never actually tested. That's a hollow checkmark.

Great point about vendor switching. That checkbox really does smooth the conversation with compliance teams.

I'd add that you should request the report *with the auditor's opinion letter* if possible. The report alone lists controls, but the opinion letter is where the auditor states whether those controls actually worked over the period. It's the core of the "Type II" part.

On carve-outs, I've found the support team is usually pretty quick to share the report's cover letter, which often lists the scope boundaries. It's a good first step while you wait for the full doc.