Document Type: Engineering Standard / Technical Reference
Document Owner: Engineering Lead
Applies To: All Vertuna engineering teams, contractors, and contributors
Effective Date:
Review Frequency: Annual (or upon significant system/architecture changes)
Version: 1.0
1. Purpose
This document formally defines the principles for engineering secure systems at Vertuna. These principles are established, documented, maintained, and applied to all system implementation efforts including:
product development (web and APIs)
infrastructure and cloud configuration
CI/CD pipelines
internal tools and administrative automation
integrations with customers and third parties
Security and privacy requirements must be treated as fundamental design constraints, not as after-the-fact controls.
2. Scope
These principles apply to all Vertuna-managed environments and systems, including:
Production and non-production environments
Databases and data stores
Service-to-service communication
Authentication, authorization, and session mechanisms
Logging, monitoring, and alerting pipelines
Data processing workflows
User-facing interfaces and APIs
3. Mandatory Implementation Requirements
Engineering must apply these principles throughout the lifecycle:
3.1 Lifecycle coverage
These principles must be considered during:
system design and architecture
development and implementation
code review
testing and security scanning
deployment and configuration
incident response and remediation
system retirement and data deletion
3.2 Evidence and artifacts
Evidence that these principles are applied may include:
architecture notes or diagrams
pull request review comments referencing security considerations
security scans (SAST / dependency scanning / DAST where applicable)
configuration hardening and network segmentation notes
incident postmortems and remediation tasks
4. Secure-by-Design Principles (Mandatory)
4.1 Minimize Attack Surface Area
Definition: Reduce exposed interfaces and unnecessary features that could be abused.
Application:
Disable unused endpoints, ports, protocols, and services
Limit exposed administrative interfaces
Keep dependencies minimal and remove unused modules
Avoid broad public access; prefer restrictive network boundaries
Examples:
expose only ports 80/443 publicly
restrict admin interfaces behind VPN / allowlist
deprecate unused API endpoints
4.2 Establish Secure Defaults
Definition: Systems must be secure by default, requiring explicit changes to reduce security.
Application:
default-deny network rules
default least-privilege roles
default encryption on storage
default logging enabled
default secure session configuration
Examples:
deny all inbound traffic except required
new services start with minimal permissions
require TLS by default
4.3 Least Privilege
Definition: Users and services must only receive the minimum permissions necessary.
Application:
role-based access control
scoped API tokens
separate roles for read vs write operations
time-limited credentials where possible
Examples:
CI/CD role can deploy but cannot access data
service accounts access only required tables
4.4 Defense in Depth
Definition: No single control should be relied on for protection.
Application:
layered controls: firewall + authentication + authorization + encryption + monitoring
compensating controls when one layer is limited
Examples:
even internal services require authentication
encryption still applied inside trusted networks
4.5 Fail Securely
Definition: When systems fail, they must fail in a secure state.
Application:
deny access on errors
avoid leaking internal details (stack traces, secrets)
fallback modes must preserve security controls
Examples:
if auth service is unavailable, reject requests
do not “fallback” to insecure mode
4.6 Don’t Trust Services
Definition: Internal services should not assume other services are benign or correct.
Application:
validate input between services
mutually authenticated service-to-service communication
enforce authorization checks per request
treat internal APIs as untrusted
Examples:
validate customer identifiers and scopes even internally
do not accept unsigned internal payloads
4.7 Separation of Duties
Definition: Sensitive functions should require separation of responsibilities to reduce abuse or error.
Application:
peer code review required
production access restricted
deployment permissions separated from development permissions
dual approval for high-risk changes
Examples:
significant changes require peer + lead approval
no single person can implement + deploy high-risk changes without review
4.8 Avoid Security by Obscurity
Definition: Security must not rely on hiding implementation details.
Application:
security relies on cryptography, access control, and validation
internal endpoints must still be protected
code and config must assume discovery
4.9 Keep Security Simple
Definition: Simple controls are more reliable than complex systems that are hard to maintain.
Application:
prefer proven patterns and libraries
avoid custom cryptography
avoid unnecessary security logic in application code
use infrastructure-level enforcement where possible
4.10 Fix Security Issues Correctly
Definition: Vulnerabilities must be fixed in a way that prevents recurrence.
Application:
identify the root cause
add regression tests where possible
review similar patterns across the codebase
apply consistent fixes across all services
Examples:
patch dependency + remove vulnerable usage patterns
add validation helpers and enforce use
5. Privacy-by-Design Principles (Mandatory)
5.1 Proactive not Reactive; Preventative not Remedial
Definition: Privacy must be designed in from the start, not added after incidents.
Application:
consider privacy risks during design
avoid collecting unnecessary personal data
implement privacy controls before launch
5.2 Privacy as the Default Setting
Definition: If no explicit action is taken, user privacy remains protected.
Application:
minimum data collection
restricted access
logging must avoid sensitive payloads by default
secure retention limits
5.3 Privacy Embedded into Design
Definition: Privacy controls must be built into core system architecture.
Application:
encryption and access control are not optional add-ons
ensure data separation across customers (tenant boundaries)
data minimization at each processing step
5.4 Full Functionality – Positive-Sum, not Zero-Sum
Definition: Achieve both privacy and functionality without trade-offs.
Application:
use anonymization, masking, or tokenization when possible
avoid unnecessary exposure for debugging or analytics
design secure observability pipelines
5.5 End-to-End Security – Full Lifecycle Protection
Definition: Privacy must be protected through the entire lifecycle: collection → storage → processing → deletion.
Application:
encryption in transit and at rest
secure deletion procedures
retention boundaries and automated deletion
5.6 Visibility and Transparency – Keep it Open
Definition: Privacy practices should be clearly understood and inspectable.
Application:
document how data is processed
maintain audit trails for access and changes
ensure internal documentation reflects actual controls
5.7 Respect for User Privacy – Keep it User-Centric
Definition: Privacy controls must align with the user’s expectations and rights.
Application:
ensure users’ data is protected from unauthorized use
avoid unnecessary profiling
ensure access boundaries (tenant isolation) are enforced
6. Practical Implementation Checklist (Engineering Use)
The following checklist must be satisfied before production deployment of significant changes:
- Attack surface minimized (ports, endpoints, unnecessary features removed)
- Authentication + authorization enforced for all entry points
- Least privilege applied (roles, service accounts, access scopes)
- Encryption in transit and at rest verified
- Logging does not expose sensitive payloads
- Input validation performed for external and internal APIs
- Peer review completed and documented
- Security scanning (dependency and static) completed
- Critical findings remediated or justified
- Privacy impact considered (data minimization, retention, exposure)
7. Technical References (Normative and Recommended)
Vertuna engineering references the following widely adopted industry sources to guide implementation:
Secure Engineering References
OWASP ASVS (Application Security Verification Standard)
baseline security requirements and controls for web/API systems
OWASP Top 10
common application security risks and mitigations
NIST SP 800-53
security and privacy controls catalog (reference for control design)
NIST SP 800-218 (SSDF)
Secure Software Development Framework
CIS Controls v8
practical security controls for small and large organizations
CIS Benchmarks
OS and system hardening baselines
Google SRE / Production Readiness Review concepts
reliability and operational risk reduction
Cloud provider security best practices (AWS/GCP/Azure)
security baselines and shared responsibility model
Privacy-by-Design References
Privacy by Design Framework (Ann Cavoukian – 7 Foundational Principles)
GDPR principles (data minimization, purpose limitation, storage limitation)
ISO/IEC 27701 (Privacy Information Management)
NIST Privacy Framework
8. Exceptions
Exceptions to these principles are allowed only when:
there is a documented business need
compensating controls exist
Engineering Lead approves the exception
exception is reviewed periodically until removed
9. Document Maintenance
This document is reviewed:
annually, and
after significant architecture changes, major incidents, or new compliance requirements
10. Document Control
| Field | Value |
|---|---|
| Document Owner | Engineering Lead |
| Approved By | Company Leadership |
| Version | 1.0 |
| Effective Date |
|
| Next Review | (12 months from effective date) |