Security is part
of the architecture.

Sensitive information deserves deliberate handling.

Customer information should be classified, shared only for an agreed purpose and made available only to those who need it. Handling arrangements should reflect the sensitivity of the information and the client’s requirements.

• Agree confidentiality and information-handling requirements.
• Use appropriate channels for transferring sensitive material.
• Review retention and disposal expectations before work begins.

Access should be intentional, limited and reviewable.

Access to systems and information should follow defined roles and the minimum permissions needed for each task. Changes in responsibilities should trigger changes in access.

• Use individual identities and appropriate authentication.
• Review privileged access and remove permissions when no longer needed.
• Record relevant access and administrative activity.

Build security into the environment.

Architecture decisions should consider trust boundaries, exposure, dependencies and recovery needs. These considerations belong alongside performance, usability and integration requirements.

• Separate systems where their risk or purpose requires it.
• Define secure configurations and a process for maintaining them.
• Include monitoring, updates and recovery in the design.

Protection follows the full lifecycle.

Data needs appropriate safeguards as it is collected, processed, stored, shared, archived and deleted. Controls should reflect its sensitivity and the systems that use it.

• Understand what data is required and where it moves.
• Consider encryption, access controls and backup protection.
• Define retention and secure deletion requirements.

Make operational ownership clear.

When systems are operated for a client, responsibilities should be agreed explicitly. Both parties need to understand what is monitored, maintained, approved and escalated.

• Document service scope and ownership.
• Assign responsibilities for changes, updates and access reviews.
• Agree reporting, dependencies and escalation contacts.

Respond through a defined process.

Potential incidents should be assessed, recorded and escalated according to their impact. A coordinated response should consider containment, preservation of relevant evidence, recovery and communication.

• Define notification routes and decision-making responsibilities.
• Preserve relevant information during investigation.
• Review findings and follow through on agreed improvements.

Plan for disruption before it happens.

Continuity starts with understanding which services matter most and how disruption would affect the business. Recovery arrangements should match these priorities and be reviewed over time.

• Identify critical systems and important dependencies.
• Agree recovery objectives and suitable backup arrangements.
• Exercise recovery procedures and document lessons learned.