Also think about

Authorisation models

RBAC - Role-Based Access Control. Users are assigned roles (admin, editor, viewer), and permissions are attached to roles rather than individuals. Simple and widely used. The right default for most applications. Gets complicated when roles proliferate or when you need fine-grained per-resource permissions.

You encounter RBAC constantly - AWS IAM roles, database user permissions, CMS permission levels are all RBAC at heart.

ABAC - Attribute-Based Access Control.Decisions are made by evaluating attributes of the user, the resource, and the environment - "allow if the user's department matches the document's department and the time is within business hours." More expressive than RBAC; also more complex to reason about and audit. Used in enterprise systems and government environments where RBAC's coarseness is insufficient.

As a CTO you will be asked to make architectural decisions between these models. The question to answer first: do your access rules depend on attributes of the resource itself, or just on who the user is? If the former, RBAC alone won't cover you.

Attacks worth knowing

SSRF - Server-Side Request Forgery. An attacker tricks your server into making HTTP requests on their behalf - typically to internal services or cloud metadata endpoints that are unreachable from the public internet. In AWS, the instance metadata endpoint (169.254.169.254) hands out temporary credentials to anyone who can reach it from the instance. An SSRF vulnerability lets an attacker reach it through your server and steal those credentials. This has been the root cause of several high-profile cloud breaches. Any feature that fetches a user-supplied URL is a potential SSRF surface - URL previews, webhooks, PDF generators, image importers.

The defence: validate and allowlist URLs server-side; block requests to private IP ranges and metadata endpoints.

Path traversal. An attacker supplies a filename like ../../etc/passwd and your server, naively joining it to a base path, reads a file it never should have exposed. Common in any feature that reads a file based on user input - file downloads, template rendering, log viewers. The defence is to resolve the full path and verify it is still inside the intended directory before opening it.

Simple in principle, frequently missed in practice.

Supply chain attacks. Rather than attacking your code directly, attackers compromise a dependency you trust - an npm package, a build tool, a CI plugin. Your code is fine; the thing it runs is not. Log4Shell (2021) was a catastrophic vulnerability in a logging library used by thousands of Java applications. The XZ Utils attack (2024) was a sophisticated two-year infiltration of a compression library that nearly shipped a backdoor into Linux SSH daemons worldwide.

As a CTO, the relevant questions are: do you have a software bill of materials (SBOM)? Do you pin dependency versions? Do you have automated vulnerability scanning in your CI pipeline? Are your build environments isolated?

Infrastructure & operations

Cloud IAM & least privilege. Every cloud service - Lambda functions, EC2 instances, ECS tasks, GitHub Actions runners - runs as an identity with attached permissions. The principle of least privilege says each identity should have exactly the permissions it needs and no more. In practice this is frequently violated: broad policies are easier to write, and nobody notices until a compromise. A Lambda that can only read one S3 bucket is a much smaller blast radius than one with s3:* on everything.

The CTO-level concern: IAM sprawl. Permissions accumulate over time and are rarely revoked. Periodic access reviews and tools like AWS IAM Access Analyzer are the operational answer.

Audit logging & SIEM. An audit log records who did what and when - not application logs, but a tamper-evident record of security-relevant events: logins, permission changes, data exports, API key creation. A SIEM (Security Information and Event Management) system aggregates logs from across your infrastructure and applies rules and anomaly detection to surface potential incidents.

You need audit logs for compliance (SOC 2, ISO 27001 both require them) and for incident response - you cannot investigate a breach without a reliable record of what happened. Design audit logging into systems from the start; it is very hard to retrofit.

Incident response. What you do when something goes wrong. Who gets called? What is your decision tree for declaring a breach? How do you communicate with affected users? What is your legal obligation for notification (GDPR requires notifying your supervisory authority within 72 hours of discovering a breach)? Do you have runbooks for common scenarios?

The time to answer these questions is not during an incident. Most organisations that handle breaches badly do so because they had no plan, not because the breach itself was uncontainable.

Compliance frameworks

SOC 2. An audit framework that examines your controls around security, availability, processing integrity, confidentiality, and privacy. Type I is a point-in-time assessment; Type II covers a period (usually 6-12 months) and is the one enterprise customers will ask for. Achieving SOC 2 Type II is often a prerequisite for selling to larger companies. It does not prescribe specific technical controls - it asks you to define your controls and then audits whether you follow them.

The practical overhead is significant: access reviews, vulnerability scanning, incident response procedures, employee security training, vendor risk assessments. Plan for 6-12 months of preparation for a first audit.

PCI-DSS. Payment Card Industry Data Security Standard. Applies if you store, process, or transmit cardholder data. Highly prescriptive - specific requirements around network segmentation, encryption, key management, logging, and penetration testing. The simplest way to reduce PCI scope is to never touch card data yourself: use Stripe, Braintree, or similar and let them handle it. If you only pass card data through your frontend to their SDK, your PCI scope is minimal.

The question a CTO should ask at the start of any payments project: what is our cardholder data environment (CDE) scope, and how do we minimise it?

Security as a process

Threat modelling. A structured way of asking "what could go wrong?" before you build something. You map out your system, identify trust boundaries, and enumerate threats against each. STRIDE is a common framework: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. The output is a list of threats, each with a severity and a mitigation. Done well, it catches architectural problems that are expensive to fix later.

Most teams do not do this formally. The minimum viable version is a one-hour whiteboard session before building any feature that touches authentication, payments, or sensitive data.

Penetration testing. Hiring external specialists to actively try to break your systems, then report what they found. Different from automated vulnerability scanning - a skilled tester will find logical flaws, chained vulnerabilities, and business logic issues that no scanner will catch. Most compliance frameworks require annual pen tests. The findings are only valuable if there is a process to remediate them.

Bug bounty programmes are a complementary approach: opening your systems to a community of researchers who report vulnerabilities in exchange for payment. HackerOne and Bugcrowd run the main platforms. Appropriate once you have enough engineering capacity to respond to findings promptly.