01
Secure design
Identify assets, actors, trust boundaries, threats, abuse paths, sensitive data, failure modes, and required controls.
Security and privacy assurance
Security treated as an engineering responsibility.
Algoza's public approach to secure delivery, access, data, dependencies, environments, release, observability, and incident readiness.
What this means
Controls must match the system and obligation.
Security requirements vary by information, users, threats, regulation, client environment, architecture, and operating model. Algoza establishes the engagement-specific control and evidence set during discovery and delivery planning.
- Least-privilege access and separation
- Sensitive information handled deliberately
- Dependencies and releases remain reviewable
- Incidents and vulnerabilities have an escalation path
Security control areas
02
Identity and access
Use appropriate authentication, least privilege, role boundaries, access review, service identities, and accountable administration.
03
Data protection
Classify sensitive data, minimise exposure, protect transfer and storage where required, and define retention and disposal responsibilities.
04
Secure development
Apply review, automated checks, testing, secrets controls, dependency assurance, and remediation proportionate to risk.
05
Environment protection
Separate environments and duties where appropriate, control configuration, restrict access, and avoid unnecessary production data in lower environments.
06
Release assurance
Use repeatable builds, approvals, deployment evidence, configuration checks, rollback planning, and post-release verification.
07
Logging and monitoring
Capture useful security and operational events, protect logs, avoid sensitive leakage, and define alert and review responsibilities.
08
Vulnerability and incident response
Provide intake, triage, ownership, containment, remediation, communication, and learning routes appropriate to the engagement.
Framework position
Standards used as references, not borrowed credentials
01
NIST Secure Software Development Framework
A useful outcome-based reference for preparing, protecting, producing, and responding across secure software delivery.
02
OWASP guidance
Application security verification and testing guidance can inform requirements and assurance appropriate to the application risk.
03
Client and regulatory controls
Client policies, contractual obligations, data requirements, sector expectations, and applicable South African law take priority where relevant.
Credentials and verification
01
No implied certification
Using a standard as a reference does not mean Algoza or a delivered system is certified against that standard.
02
No unverified badges
A certification, partner status, competency, or accreditation should be published only when current, scoped, and independently verifiable.
03
Due diligence by scope
Relevant security, privacy, architecture, delivery, and company evidence can be addressed through the appropriate procurement or engagement process.
Public security statement
This page is a public overview, not a security guarantee, audit report, certification, penetration-test result, or substitute for engagement-specific due diligence. Detailed controls and evidence may be confidential and depend on the agreed scope and client environment.
Related assurance
Inspect the connected practices
Need security information for due diligence?
Share the proposed engagement, data context, procurement requirement, and evidence requested. Algoza will confirm what can be provided and under what confidentiality conditions.