Security starts with a clear plan.

Identify the information the product handles, the people who need access and the consequences of a failure. Share relevant procurement requirements and internal policies during discovery so they can be assessed before a scope is agreed.

• What data is needed, and can development use synthetic or de-identified data?
• Where may data be stored or processed, and which providers need approval?
• Who grants access, at what level, and how is it reviewed and removed?
• Who owns credentials, backups, retention and deletion decisions?

• Which code reviews, automated checks and acceptance tests are required?
• How are environments separated and changes approved for production?
• Which security reviews are in scope, and does independent testing need a separate provider?
• What recovery procedure and evidence are needed before release?

For AI work, agree what information may leave your environment, which models and providers are permitted, and the applicable retention and training settings. Define evaluation criteria, human review, failure handling and permissions for any action the system can take.

Identify the owner of monitoring, patching, incident response and recovery. Specify support hours, response targets and escalation paths in any support agreement. Delivery of a product does not by itself define an ongoing support service.

Confidentiality arrangements, intellectual property, licensing, service levels and acceptance terms belong in the agreed contract. If your procurement process needs certifications, references, insurance details or particular technical evidence, identify those requirements early so their availability and relevance can be confirmed.

This guide outlines questions for scoping. It does not assert a certification, regulatory compliance or a control that applies to every engagement.

Discuss your requirements