Skip to main content
Review and revision metadata
Review Date: 2026-07-05
Reviewer: Solution Architect

previous version on gdrive

A.8.27 Secure System Architecture and Engineering Principles

Control Objective

Principles for engineering secure systems shall be established, documented, maintained and applied to any information system development activities.

Policy Statement

anDREa establishes and enforces definitive architectural and engineering principles across all information system development lifecycles. These principles guarantee that the myDRE platform is built defensively from its inception, utilizing robust identity boundaries, functional isolation, and rigorous environment segregation to protect tenant infrastructure and maintain systemic resilience.


1. Fundamental & Governance Frameworks

Our system design philosophy is driven by three foundational pillars: the aSecurity Manifesto, the Assessment Framework for Services, and our formal GDPR Compliance Assessment.

To ensure these principles are actively maintained at the code layer:

  • All technical and development personnel undergo mandatory annual training in secure coding frameworks.
  • Annual Compliance Verification: Engineering teams must demonstrate continuous technical knowledge by completing the Secure Coding and Complianze Quiz, with individual scores and responses formally logged for audit visibility.

2. Comprehensive Lifecycle Principles

anDREa organizes its architectural guardrails across five distinct phases of the system lifecycle:


[Design] ➔ [Development] ➔ [Testing] ➔ [Acceptance] ➔ [Deployment]

A. Architecture & Design Principles

All software concepts must be designed defensively based on both standard user stories and anti-user stories (abuse cases), governed by explicit acceptance criteria:

  • Defense-in-Depth & Containment: System features must be isolated so they can be completely deactivated or switched off without destabilizing or affecting the rest of the myDRE platform.
  • Unified Access Rules: Application boundaries enforce the principle of Least Privilege, Role-Based Access Control (RBAC), and multi-factor authentication (MFA) for all active entry points. System logging must strictly align with the Assessment Framework for Services.
  • Secure Workspace Variations: Any user-initiated configuration change within a myDRE Workspace must be:
    • Deliberate & Controlled: Restricted strictly by user role and the least-privilege baseline.
    • Transparent: Clearly display the immediate impact on security or auditability, providing actionable steps to maximize compliance and reduce risk.
    • Consensual & Reversible: Explicitly log user consent while ensuring configurations are mathematically straightforward to revert back to platform defaults.

B. Development Principles

  • Code Craftsmanship: Features must be built utilizing clean code standards, comprehensive technical documentation, and rigid adherence to naming conventions and structural layouts defined by senior anDREa developers.
  • Mandatory Peer Reviews: Every single code modification must undergo formal, documented peer review before merging.
  • Absolute Isolation: Code construction runs entirely on local developer environments, completely disconnected from Test, Acceptance, and Production environments. Production data is strictly prohibited within development cycles.

C. Testing Principles

  • Validation Vectors: Testing must be verified against both functional acceptance criteria and security anti-user stories.
  • Environmental Segregation: Testing actions occur inside isolated cloud sandboxes, strictly separated from Development, Acceptance, and Production infrastructures, operating with entirely non-live synthetic data.

D. Acceptance Principles

  • Smoke Testing: Verification of application functionality purely from an end-user perspective and functional expectation baseline.
  • Compliance Checks: Final confirmation that the code complies with the Patching Performance, with validation metrics recorded within our version control repositories.

E. Deployment (Production) Principles

  • Smoke Validation: Execution of post-deployment smoke tests within production bounds.
  • Tenant Billing Isolation: Client environments are automatically deployed into distinct Azure Subscriptions tied directly to their own organizational billing accounts.
  • Privileged Elevation Guardrails: Access to core systems is disabled by default. If a Research Support Team (RST) member requires portal access to execute authorized administrative tasks, they must dynamically elevate their access using Privileged Identity Management (PIM).
  • Stakeholder Coordination: Deployments require proactive communication to internal Support Teams alongside immediate publication of updated user manuals and RST support documentation.
  • Emergency Fallbacks: In the event of an unexpected post-deployment failure or security anomaly, operations teams must instantly execute emergency procedures to either switch off the affected functionality or revert the platform state back to the previous stable release.
note