5 Expect? Technical Control Objectives
What should be in place, and what does “good” actually look like?
🗂️ Tessera Case: The diagram is not the territory
Tessera’s head of engineering hands you a single-page architecture diagram early in the engagement. It is beautiful. Boxes for VPCs and subnets, arrows labelled TLS, a padlock on the database, “KMS” stamped on every storage layer, “IAM roles” on every service. He watches you study it, looking for the nod. You give him a different response. You ask, for each box: what is the objective here, and how would I test whether it is actually met? The diagram is a claim. Your job, from this chapter on, is to turn each claim into a control objective you can substantiate, or refute, with evidence.
5.1 From control to control objective
Chapter 4’s small procedure is a starting point. The control objective is the tool that turns a list of controls into an audit.
A control is a safeguard. Encryption is a control. A firewall rule is a control. Multi-factor authentication is a control. A control objective is the intent that control is meant to deliver, written so that intent can be tested. “We encrypt the database” is a control. “Requests through the tested customer-data API require an authorisation decision, with sufficient logging to reconstruct access” is an objective. The first describes a configuration. The second describes an outcome you can try to disprove. That is the difference between auditing a screenshot and auditing a system.
ISO/IEC 27001:2022 gives you the raw material in Annex A.8, the Technological controls, the largest of the standard’s four themes. NIST CSF 2.0’s Protect function and the ASD Essential Eight give you the same engineering from different angles. None of them hands you the objective. That is your job, and it is the job this chapter teaches: read the control, ask what “good” looks like, phrase it as a statement you could prove or disprove with evidence, and then go look.
Here is a useful test for whether you have written an objective rather than a control. Can you describe how it would fail silently? If you cannot, clarify the mechanism and likely failure conditions before choosing a test. The objective is only real once you can picture the version of the world in which the control is present, the dashboard is green, and the objective is still not met. That picture is what you will spend the rest of the engagement trying to find.
5.2 Access control: identity is the new perimeter
For a SaaS company like Tessera there is no perimeter in the old sense. There is no castle with a wall and a moat. There is a set of identities, human and machine, each holding some set of permissions, talking to services that live on someone else’s hardware. Get identity right and most of your technical risk falls into line. Get it wrong and nothing else matters, because the attacker walks through the front door with valid credentials.
The first objective is least privilege: every identity, human or service, holds only the permissions it needs, and nothing more. That sounds tidy until you ask for the access review and find the founding engineers still hold administrator rights across production, staging, and every customer tenant, because nobody has ever pruned them. A review may reveal inherited privileges, or may substantiate that they remain justified. Least privilege maps to ISO 27001 A.8.2 (privileged access rights) and A.8.3 (information access restriction), and to the Essential Eight’s “restrict administrative privileges” strategy. The objective, though, is the testable version: any permission not justified by current job function is removed within a defined window.
The second is authentication strength: access requires proof of identity proportionate to the risk, and for anything privileged, that proof resists phishing. Passwords alone fail this objective, and so does a six-digit SMS code relayed to a tired person at midnight. Phishing-resistant MFA, the kind built on FIDO2 and WebAuthn, is what “good” looks like for administrators and for anyone touching customer data. The Essential Eight pushes you here for a reason.
The third is the identity lifecycle: accounts are created when someone joins, changed when their role moves, and removed when they leave, on a clock you can measure. The leaver control is the one that fails quietly, because the person is already gone and nobody is watching the account. Federation through SAML or OIDC, single sign-on, and automated provisioning through SCIM are how mature organisations make the lifecycle a system rather than a memory.
The fourth is privileged access specifically. Administrators do not sit in a standing admin role all day. They elevate when they need to, for as long as they need to, and what they do while elevated is recorded. This is privileged access management: just-in-time elevation, break-glass accounts for emergencies, session recording, and time-boxed grants. The objective is not “we have PAM tooling.” The objective is no privileged action occurs without a time-limited, logged, reviewable elevation.
5.3 Network security: assume the breach
The old network question was “can the attacker get in?” The modern question, the one a zero-trust mindset demands, is “once the attacker is in, how far can they get?” NIST SP 800-207 describes zero trust without implicit trust based solely on network location or asset ownership. Authentication and authorisation precede access to a resource. For a company whose entire estate is API calls to AWS, the network is already hostile by design.
Segmentation is the engineering of that mindset. Tessera’s VPCs, subnets, security groups, and network ACLs should carve the estate into zones that contain blast radius. Production separate from staging. Customer-facing services separate from internal tooling. Databases reachable only from the application tier, never from the open internet. Each of those is a control; the objective is that an attacker who compromises one component cannot traverse to another without a fresh access decision. That is the difference between a breached container and a breached company.
Firewalls and security groups are the mechanism, but they are only as good as their rules, and rule drift is where segmentation goes to die. The rule opened for a vendor demo eighteen months ago and never closed. The 0.0.0.0/0 that someone applied to make a test pass. The database port exposed to the office range because a developer wanted to work from home. The objective is not “we use security groups.” It is every rule is justified, scoped to least access, and reviewed on a schedule, which is a test you can actually run against the live configuration.
5.4 Cryptography and key management: the control that fails silently
Encryption is where auditors go wrong, because encryption looks finished. The dashboard says “at rest: enabled.” The browser shows the padlock. Do not tick the box and move on.
Encryption at rest and in transit is the baseline, not the achievement. The achievement is key management, and it is where a cryptography control that looks perfect can be substantively broken. AWS Key Management Service (KMS) and hardware security modules (HSMs) exist to keep keys out of the data they protect. Customer-managed keys give Tessera control over who can use a key and when, through policies and grants that are themselves auditable. Key rotation introduces new key material but does not by itself revoke access or neutralise exposed historical ciphertext. AWS documents that KMS retains earlier material for decryption; investigate exposure and permissions separately. Separation of duties limits the damage of a rogue insider. ISO 27001 A.8.24 (use of cryptography) points here, and the Essential Eight’s expectations on backups and data protection lean on the same foundation.
Now picture the failure. Encryption is enabled on every S3 bucket. The dashboard is green. But the application role that reads customer data holds a KMS grant for a single key used by every tenant. One compromised token, one over-permissive policy, and the attacker decrypts everyone’s data at once. This is an application-role compromise with decrypt permission, not storage theft alone. Test those threat models separately; the presence of encryption does not prevent misuse of an authorised decrypt path. This is the silent failure, and it is exactly the kind of gap a control objective, not a control list, will catch.
5.5 Multi-tenant SaaS: isolation is the whole product
Tessera is a multi-tenant SaaS. Customers share the same application, the same databases, the same infrastructure. The product they are paying for is, at root, the promise that they cannot see each other. Get tenant isolation wrong and the problem is existential.
Layered controls enforce tenant isolation: per-tenant identity and namespace boundaries in IAM, row-level or logical separation in shared data stores, and, for the most sensitive work, per-tenant encryption keys with separately controlled decrypt permissions. Whether an administrator can recover plaintext depends on the architecture and effective permissions. The classic failure has a name: insecure direct object reference, where a request for /api/tenant/1043/data is honoured for an authenticated user who belongs to tenant 1077, because nobody checked the relationship. IDOR is the silent failure of multi-tenancy, and it is widespread because it fails open: the request succeeds, the log looks normal, nobody is alerted.
State the tested boundary and threat model. For E11, an ordinary authenticated tenant A user must not read tenant B’s record by changing an API identifier; unauthenticated requests must also be denied. That is testable. It does not cover compromise of a trusted application role, an administrator, every interface or every error path.
Customer-managed KMS keys and bring-your-own-key arrangements do not automatically prevent the service from decrypting. Inspect key policy, grants, service integration and who can alter them. A design in which only the customer can decrypt is a different architectural claim and needs its own evidence.
5.7 The question, answered
Technical assurance starts with a defined objective, a threat model and evidence of the tested decisions. E11 clears a specific concern without establishing universal isolation. The next chapter places those technical objectives within people, physical and management-system controls.