Safety Norms: Cloud Architecture Planning

1Purpose, Scope, and Safety Principles

This document sets out norms for planning cloud architectures, the design work that decides how applications, data, networks, identities, and recovery capabilities are arranged in a cloud environment. Its purpose is to prevent harm to people, customer data, and business operations caused by poor design decisions, and to support practice that is secure, reliable, and compliant.

The scope includes architecture diagrams, landing zone design, account and subscription structure, network segmentation, identity and access models, data classification and residency choices, backup and disaster recovery targets, cost plans, and the handoff of designs to build teams. It applies to students, employees, and contractors working in sandbox, lab, or planning environments that may connect to production systems.

• Mandatory: never place real customer or personal data in a training or sandbox environment without written approval from the data owner.
• Mandatory: do not probe, scan, or test any cloud account, endpoint, or service that you do not own or are not authorized in writing to assess.
• Recommended: treat every design as a hypothesis that must be reviewed, tested in a controlled environment, and revised when evidence shows a gap.
• Principles: least privilege, defense in depth, secure by default, and designing for failure, meaning every component is expected to fail and must have a defined response.

2Roles, Competence, and Accountability

The design owner, usually the lead cloud architect, is accountable for the completeness of the architecture document and for recording each risk decision. The security reviewer checks identity, network exposure, encryption, and logging. The data owner decides classification and retention for each dataset. The operations lead confirms that monitoring, backup, and runbooks are feasible. The privacy or compliance lead confirms obligations for personal, financial, health, and other regulated data. The project sponsor approves residual risk that the design cannot remove.

Competence matters because cloud services change frequently and misconfiguration is a common source of exposure. Only people with documented training or supervised experience should make production-facing decisions about identity, encryption key management, or network exposure. Students and new staff work under a named reviewer. Nobody approves their own design, and no one accepts risk on behalf of a team that did not agree to it.

• Design owner signs the architecture decision record before handoff to build teams.
• Security reviewer must approve any design that exposes a service to the public internet.
• Data owner signs off on classification before data is placed in a new region, account, or managed service.
• Supervisors confirm that reviewers have current access rights for the tools they use and that those rights match their role.

3Course-Specific Hazards and Risk Assessment

Realistic hazards in cloud architecture planning include overly broad permissions, publicly readable storage or databases, unencrypted data in transit or at rest, single points of failure, untracked cross-region data movement, credentials embedded in code or diagrams, shared administrative accounts, and cost overruns from unbounded scaling. Operational hazards include recovery targets the team cannot meet in practice and vendor lock-in that leaves no tested exit path.

Score each hazard by likelihood and impact using the organization's risk matrix. Where no matrix exists, use a simple five-point scale for each factor and multiply the results. Any risk in the highest band blocks approval until a named owner mitigates it or accepts it in writing. Record the assessment in the design document and repeat it whenever the data class, exposure, or dependency map changes.

• Identity: root, owner, or global administrator credentials used for daily work are a high risk and must not be used.
• Exposure: any public endpoint requires a documented business justification, a filtering layer where appropriate, and logging before approval.
• Data movement: cross-border or cross-region transfer requires a data owner decision and a check against applicable privacy and sovereignty rules, which are jurisdiction-dependent.
• Resilience: a critical service without a restore test is treated as high risk until recovery has been demonstrated in a controlled exercise.
• Cost: a budget alert and a service quota must exist before any load or scaling experiment begins.

4Preventive Controls and Safe Design Practices

Prevent unsafe designs at the drawing stage. Use approved reference architectures or landing zone patterns where the organization provides them, and document each deviation. Separate development, test, and production environments into distinct accounts or subscriptions, and keep production administrative access out of planning tools. Define tagging standards for owner, data class, environment, and cost center so that every resource can be traced to an accountable person.

Design for failure. Identify each component's failure modes, define recovery time and recovery point objectives agreed with the business, and spread redundant components across fault domains where the provider supports it. Maintain a dependency map so that a single change does not silently break several services. Changes to an approved design require a new review, a rollback plan, and a record of the approver.

Make each control testable. A statement such as storage is private should be checked by a policy-as-code rule or a documented configuration review. Record who verified the control and the evidence used, so an auditor or future reviewer can repeat the check.

• Mandatory: encrypt data in transit using current protocols and encrypt data at rest using managed or customer-managed keys as the data class requires.
• Mandatory: no hard-coded secrets in diagrams, templates, or repositories. Use a managed secrets service with access logging.
• Mandatory: all administrative access uses multifactor authentication and time-limited elevation approved by the security reviewer.
• Mandatory: production changes are deployed only from reviewed infrastructure as code, not from manual console edits.
• Recommended: a second engineer reviews every infrastructure template before deployment.
• Recommended: use provider-native guardrails that block unapproved regions, public storage, and disabled logging.

5Access, Privacy, and Information Safeguards

Access to cloud planning tools, diagrams, and environments follows least privilege. Grant read access to design documents by need to know, give write or deployment rights only to named roles, and review those grants at the interval set by policy. Remove access promptly when a person changes role or leaves the project.

Privacy safeguards start with a data inventory. Each design must identify personal, financial, health, and other sensitive data and record where it is stored, processed, logged, and backed up. Logs often capture personal data unintentionally, so logging design must include masking and retention limits. Diagrams shared outside the team may reveal account identifiers, address ranges, and internal system names, so sanitize them before sharing. Legal requirements for privacy and data residency are jurisdiction-dependent and must be verified with the privacy lead or qualified counsel.

• Mandatory: no production credentials, keys, or customer records in screenshots, tickets, chat messages, or email.
• Mandatory: sanitize architecture diagrams before any external sharing and remove account numbers and internal addresses.
• Recommended: label documents using the organization's information classification scheme.
• Recommended: keep planning artifacts in an approved repository with version history and access logging.

6Authorized Testing and Operational Reliability

Testing a design is valuable, but testing must never become unauthorized probing. Test only resources you own or have written authorization to test, within the scope, time window, and rules of engagement agreed in advance. Automated scanning, load testing, and failover exercises can disrupt shared services and may breach cloud provider acceptable use terms. Check the current testing policy for each provider directly, because those terms differ and change.

Keep a test plan that lists the target, tester, authorization reference, expected impact, stop conditions, and cleanup steps. Stop any test that produces unexpected customer impact and report it under the incident process. Failover tests in production require change approval, a rollback plan, and a qualified operator present. Any test that could cause data loss must be performed only by qualified personnel.

• Mandatory: written authorization and a defined scope exist before any security test, penetration test, or load test begins.
• Mandatory: backups are verified by restore testing, not assumed to work because a job reports success.
• Mandatory: recovery objectives are reviewed with the business owner before they are written into the design.
• Recommended: failure injection runs only in non-production environments with a documented stop condition.

7Incident Response, Escalation, and Emergencies

Report suspected security events, data exposure, misconfigurations found in designs or live environments, and near misses immediately to the security on-call contact and the design owner. Do not attempt to repair a live production incident unless the incident runbook authorizes you to do so. Preserve evidence by keeping logs, snapshots, and affected resources intact until the investigation lead releases them.

Escalation follows the organization's incident response plan. Contain first, notify second, and investigate third. Notification of customers, regulators, or affected individuals may be legally required within timeframes that vary by jurisdiction, so the privacy or legal lead decides and documents those obligations. For any physical emergency at a facility or workplace, contact local emergency services first. A cloud incident response process does not replace emergency response.

• Rotate any credential suspected of exposure immediately using the runbook steps and record the time of rotation.
• Record each incident with the time observed, systems affected, observed impact, and containment actions taken.
• Never bypass a provider or organizational control to speed recovery without security approval.
• Do not discuss suspected incidents in public channels or on social media.

8Records, Training, Review, and Continuous Improvement

Maintain an architecture decision record for every significant choice, including the alternatives considered, the risks accepted, the approver, and the trigger for review. Store these records in an approved repository with access control. Retention periods depend on organizational policy and applicable law and must be confirmed locally.

Training should cover secure design principles, the organization's landing zone standards, privacy basics, and incident reporting. Refresh training when provider services or internal standards change. Review each architecture when its scope, data class, or threat model changes and after any incident. Track metrics such as open high-risk findings and overdue reviews, and use them to improve the planning process rather than to assign blame.

• Mandatory: every production-bound design has a named owner, a named security reviewer, and a recorded risk acceptance.
• Mandatory: findings from reviews, tests, and incidents are logged and assigned an owner with a due date.
• Recommended: hold a short peer review of each design document before approval.
• Recommended: retire unused resources and outdated diagrams during each scheduled review.

Implementation checklist

• Confirm the design owner, security reviewer, and data owner are named in the decision record.
• Classify all data and confirm the location and residency decision with the data owner.
• Remove public exposure unless a documented justification and security approval exist.
• Verify least privilege for every role and eliminate shared or root-level daily access.
• Confirm encryption in transit and at rest, and confirm secrets are held in a managed service.
• Document recovery objectives with the business owner and schedule a restore test.
• Obtain written authorization and a defined scope before any security or load test.
• Sanitize diagrams and remove credentials and personal data from shared artifacts.
• Record risks, mitigations, and accepted residual risk in the decision record.
• Set a review date and re-review triggers for changes, incidents, and new data classes.