System quality attributes

The previous module put privacy and auditability on a legal footing: the UK GDPR's seven principles, the Data (Use and Access) Act 2025 and the Computer Misuse Act 1990. This module widens the same move from the legal frame to the engineering one, because the properties a regulator demands are, to an architect, quality characteristics to be specified and measured. ISO/IEC 25010:2023 (the SQuaRE system and software quality model) defines eight top-level product quality characteristics: Functional Suitability, Performance Efficiency, Compatibility, Interaction Capability, Reliability, Security, Maintainability, and Flexibility. Security sits in that list as a peer, not as a separate compliance exercise, and it decomposes into five sub-characteristics:

• Confidentiality: data is accessible only to authorised entities.
• Integrity: the system prevents unauthorised access to or modification of data.
• Non-repudiation: actions can be proven to have taken place.
• Accountability: actions can be traced uniquely to the entity that performed them.
• Authenticity: the identity of a subject can be proven to be the one claimed.

Two of these should feel familiar. Confidentiality and integrity are two thirds of the CIA triad from the foundations stage, and the third leg has not disappeared: ISO 25010 files availability under Reliability, as the question of whether the system is operational and accessible when required. The remaining three sub-characteristics extend the triad into questions of proof: can an action be denied later, can it be traced to exactly one actor, and is that actor who they claim to be. The decomposition is what makes security testable, because each sub-characteristic can carry its own measures and its own acceptance criteria instead of one vague demand to be secure.

Treating security as a quality characteristic has practical consequences. Security requirements are managed with the same requirements engineering practices as functional requirements; security quality is measured and tracked alongside reliability and performance; and a security regression triggers the same response as a performance regression, not a quieter one. The secure software development lifecycle module closed by writing security requirements as non-functional requirements; the quality model is where those requirements get their vocabulary. A poor NFR: "The system must be secure." A well-formed NFR names the sub-characteristic, the measure and the verification: "All customer payment data transmitted between the client application and the backend API must be encrypted using TLS 1.2 or higher. Connections on TLS 1.1 or below must be rejected. Compliance is verified by automated test TC-TLS-001, which connects to all production API endpoints using a TLS 1.1 client and confirms a connection failure." That requirement is Confidentiality made checkable, and the figure below places it in the model it came from.

Because security is one characteristic among eight, it competes for the same design budget as the other seven, and the competition is structural rather than accidental. A control that strengthens one sub-characteristic almost always spends from another characteristic's account. The professional response is documented trade-off analysis: state which characteristics are in tension, measure what each option costs, and decide on the record. The failure mode is silent de-prioritisation, where one characteristic quietly loses without anyone having agreed that it should.

Security versus Interaction Capability (usability): multi-factor authentication increases Authenticity but adds login friction, and friction is not a soft cost: users who find the front door painful build side doors, sharing accounts or pushing work to unmanaged tools. The resolution is rarely to abandon the control. Contextual MFA prompts only on new devices or unusual locations; passkeys built on FIDO2 and WebAuthn remove both the password and the one-time-code friction at the same time as strengthening Authenticity; and user research finds the friction level at which adoption materially drops, so the trade-off is measured rather than guessed.

Security versus Performance Efficiency: full-disk encryption, field-level encryption, and certificate verification all add measurable latency. The disciplined pattern is to measure a performance baseline before and after the control, prefer efficient implementations (AES-GCM with hardware acceleration, TLS session resumption), and agree an explicit latency budget for security overhead so that "too slow" is a number, not a mood.

Security versus Maintainability: the least discussed tension. Every additional control is also code and configuration that future engineers must understand: a finely segmented network is harder to change, a bespoke cryptography wrapper is harder to upgrade, and an access model with hundreds of roles invites misconfiguration. None of this argues against the controls. It argues for costing them honestly, because a control nobody can safely modify becomes next year's vulnerability. The opening story is what honest costing looks like at national scale: the NHS app design set out the consequences it could identify for the option it did not take, said which of them it could not size, and named who should weigh them. The decision can still be read years later precisely because the reasoning was written down, not because it was free.

A documented trade-off is a snapshot, and systems do not hold still for snapshots. Dependencies update, engineers join and leave, a hotfix bypasses the agreed pattern, and eighteen months later the property everyone decided to protect has quietly eroded. The discipline that keeps a decided quality property true over time is the architectural fitness function, a term from Ford, Parsons and Kua's "Building Evolutionary Architectures" (O'Reilly, 2017): an objective, automated measurement of an architectural characteristic, run continuously in the CI/CD pipeline rather than checked once at a design review.

Concrete security fitness functions look like this. A Trufflehog scan on every pull request fails if a secret pattern is detected, enforcing that no credentials live in source code. A Trivy scan fails the build on any CRITICAL CVE, so no vulnerable container image is promoted. The TC-TLS-001 test from section 1 runs against every production endpoint and fails if a TLS 1.1 client can connect, keeping the Confidentiality NFR true after every deployment. A performance test blocks release if p99 latency under security controls exceeds the 200ms budget, which protects the other side of the section 2 trade-off: the latency budget the business agreed to spend on security is also a ceiling. And a build step that publishes a current software bill of materials and fails if any component appears in the CISA Known Exploited Vulnerabilities catalogue turns the prioritisation logic from the vulnerability management module into an enforced property of every release.

The design choice that decides whether any of this works is blocking versus warning. A fitness function that only raises a warning records decay; one that fails the build prevents it. Warnings accumulate, become wallpaper, and train teams to ignore the channel that was meant to protect the property. Exceptions will still be needed, because real delivery sometimes has to ship with a known gap. The professional form of an exception is a time-boxed waiver with a named owner and an expiry date, the same shape as the patching SLAs from the vulnerability management module, so that an exception left to rot shows up as overdue rather than passing as normal. Seen this way, fitness functions are how the secure development lifecycle's gates survive contact with delivery pressure: the gate is not a meeting, it is a test that runs whether or not anyone remembers to hold the meeting.

Fitness functions stop new erosion, but every real organisation already carries a stock of known weaknesses from before the gates existed. Security debt is that stock: the accumulation of known security deficiencies not yet remediated, whether by explicit decision or by drift. It includes patches deferred beyond their SLA, controls omitted during development, threat models that no longer match the system they describe, and compliance gaps documented but unclosed. The borrowing metaphor is earned, because the debt accrues interest: the longer a weakness stands, the more attacker tooling learns to find it and the more systems grow to depend on the weak component.

The canonical compounding failure is Equifax in 2017. The vulnerability that opened the breach, in the Apache Struts web framework, had a patch available for roughly two months before the intrusion began: the flaw was known, catalogued and fixable, which is exactly what makes it debt rather than surprise. The unpaid debt compounded into the exposure of personal data on around 147 million people, and in 2023 the UK Financial Conduct Authority fined Equifax Ltd £11 million over the failures affecting UK consumers' data caught up in the breach. Every step of that sequence was a known deficiency ageing past the date someone should have acted on it.

Debt you cannot count, you cannot manage, so measurement comes first:

1. Inventory: enumerate all open findings from SAST, DAST, penetration tests, vulnerability scans, and compliance assessments.
2. Score: assign severity and a remediation cost estimate to each item.
3. Age: calculate days overdue beyond the defined SLA per severity tier.
4. Aggregate: total security debt = sum of (overdue items × severity weight × remediation cost estimate).
5. Trend: is the debt increasing or decreasing, and at what rate?

Weight the inventory by exploitation evidence, not severity labels alone: a MEDIUM finding on the KEV catalogue outranks a HIGH that nobody is exploiting, which is the CVSS-plus-EPSS discipline the vulnerability management module built. Then translate for the audience that funds remediation. For a board: "We have three unmitigated CRITICAL vulnerabilities in our payments API. If exploited, they could expose all customer payment records, with ICO fine exposure of up to 4% of global annual turnover and reputational impact comparable to the British Airways £20 million fine." Compare remediation cost to breach cost: "Fixing these three issues requires approximately 15 engineering days. A breach at our scale would likely cost £2 to 10 million in fines, incident response, customer notification, and reputational impact." The trend line matters as much as the total: a debt number falling quarter on quarter is a system under control, while a rising trend under flat headcount is a request for funding expressed in data.

Everything so far happens inside engineering: quality models, trade-off analyses, pipelines, debt registers. For any of it to hold, someone above the engineering organisation has to own the balance, and that is the change the current framework revision made explicit. NIST CSF 2.0 (published 2024) adds a sixth function to the original five: Govern (GV) for cybersecurity risk strategy, roles, and policy; Identify (ID) for asset management and risk assessment; Protect (PR) for access control and data security; Detect (DE) for monitoring and anomaly detection; Respond (RS) for incident response; and Recover (RC) for recovery planning. The Govern function recognises that security is a governance and quality concern, not only a technical one, which aligns it with ISO 25010:2023's framing of security as a characteristic to be balanced rather than a department to be consulted.

Govern is also where the board's risk appetite becomes engineering's targets. An appetite statement such as "no internet-facing service carries a known exploited vulnerability for more than 14 days" descends through Identify and Protect as patching SLAs, becomes a blocking fitness function in the pipeline, and reports back upward as the security debt trend from section 4. That loop, appetite flowing down and measurement flowing up, is what the figure below draws with Govern at the hub of the other five functions. When the loop is missing, the symptoms are familiar: engineers guessing what level of protection the business wants, and boards discovering their real risk position only after an incident.

The last piece is the record. A security trade-off decision worth making is worth writing down with five fields: the options considered, the metric used to evaluate them, the decision taken, the named owner, and the review date. "We chose performance" is not a decision record; it is a missing one. The review date is the field teams most often omit and most often regret, because a trade-off that was correct at design time decays as attacker capability, system load and regulation change. The NHS app team's published review is the pattern scaled up to national visibility; a two-page record in the repository is the same pattern at everyday scale, and it is what turns this module's analysis into something an auditor, a successor or a regulator can follow years later.