Security is built, not declared

Confidentiality needs are identified during framing. The necessary commitments are defined with the organization before data is shared.

Access profiles, rights and necessary traces are defined according to the scope, tools and responsibilities of the project.

Data useful to the project is examined with the organization; anonymization, pseudonymization or test data may be selected as appropriate.

Retention periods and the terms for withdrawal, return or deletion are defined with the organization and its applicable requirements.

Data protection needs are considered in the scope, flows and responsibilities to be defined with the organization.

Data needed for the project purpose is identified and the collection scope is discussed with the relevant teams.

Roles, contacts and the processing points to examine are clarified in the project framing.

Documentation useful to project follow-up is identified with the organization, according to its context and requirements.

Location, provider and hosting constraints are selected according to the project, the data and the organization’s rules.

Encryption needs in transit and at rest are defined with the organization according to the flows, tools and sensitivity of the data.

Needs to separate environments, datasets and uses are examined during technical framing.

Events, access and operations to trace are determined with the organization to support the intended system follow-up.

Changes are reviewed according to their scope, with attention to possible effects on access, data and operations.

Relevant controls and tests are defined with the build scope and the risks identified for the project.

Dependency monitoring and patch-prioritization arrangements are defined for the operating environment.

Update, follow-up and recovery conditions are to be defined with the organization before operation.