Open rdegraaf opened 1 month ago
In a more general sense, this also applies to Web Profile: are only public-facing things in scope, or are internal microservice APIs in scope as well? Are only components that deal with data retrieved from ADA Member applications in scope or are all application components in scope? Etc.
In my experience with the current ADA verification process, this is where conversations get a little complicated with customers. I personally would prefer to go with any externally accessible asset which holds or processes data retrieved from an ADA Member that is wholly owned and maintained by the customer.
Unless there are blockers within the cloud profiles (or other profiles) that we must resolve now, I'd like to defer this issue until after v1.0 and pending the completion of the ADA's certification policies and procedures documents. I think we'll be in a better position to reason about this issue then.
During discussions for the Cloud Profile, we seem to have made the implicit assumption that 1 application == 1 Cloud environment (AWS account, etc.). This is not always accurate: some development teams prefer to use one environment per microservice, or share some components with other applications, or split things up in other ways. Many teams have separate environments for development, testing, and production. When more than one Cloud environment is used by an application, it's not clear which environments must be assessed for ADA compliance.
Some options:
Depending on which option we choose, this could mean the difference between assessing one account or assessing 10 or more. When third-party assessors are employed, this means a significant difference in assessment cost.