It can be a very long and nuanced conversation, but just to give a kind of summary, if you look at something like what they have in the United States, there's a security control framework based on a NIST standard called FedRAMP that lists something like 250 controls—in other words, the security properties that you want in a system—and if you take that whole security framework, our platform covers more than one-third of those controls. There are simply things that we literally take care of on behalf of our customers. They don't have to worry about them at all. Roughly one-third are shared in that we take care of some of the things but the customer has to do certain configurations and make certain choices that are correct for their requirements. Those are optional because it's reasonable to do either one, but depending on what their needs are, they have to choose. Then roughly one-third are pretty much all the responsibility of the customer.
So we have decreased the scope of concern for the customer. We delineate pretty clearly, and we literally have control documents that say who's responsible for what, and then we have a lot of material—white papers, best practices documents, and what we call a “well-architected framework”—to help people with that one remaining responsibility. We want them to be very successful at that, so we put a lot of effort into helping them design secure systems.
But when you get to that level, it all depends on the needs of the application, so there's not a correct answer to some question. It's going to be “it depends”. It depends on the application. It depends on the requirement.
In general, I think that's a good summary of the kind of model we use with our customers. We take care of a number of things that they normally would worry about; we describe some areas in which we do some things and they need to do others, and then we help them be successful in the remaining parts of building a secure system with lots of tools and features that make it easy to do the remainder.