6 Assess? Physical, People, and ISMS Controls: Preliminary Readiness
How much can you honestly say about a company you have only ever read about?
🗂️ Tessera Case: Act I closes
Act I has examined the mandate and selected design records, especially E01–E03. The policies name responsibilities and expected performance. They also contain a two-hour/24-hour conflict and unsubstantiated “implemented” statuses. You can identify those design issues now; historical operating records are released in Act II for this staged exercise. Real audits need not defer interviews or operating evidence for six weeks.
6.1 What Act I let you do
Chapter 5 taught you the technological control objectives: access, network, cryptography, the AWS shared-responsibility split. Those sit in Theme A.8, the thirty-four technological controls. This chapter assesses the other three families the 2022 standard clusters controls into, plus the management system that holds them together.
The people controls (Theme A.6, eight controls) govern the human side: who you hire, what you make them agree to, how you train them, and what happens when they leave. The physical controls (Theme A.7, fourteen controls) govern offices, devices, and the environment they sit in. The organizational controls (Theme A.5, thirty-seven controls) are the largest family, and they sweep up everything that is neither purely human nor purely physical: policies, asset management, supplier relationships, classification, and the cloud services Tessera runs on.
Around all ninety-three controls sits the ISMS itself, the management system defined in Clauses 4 through 10 of ISO/IEC 27001: context, leadership, planning, support, operation, performance evaluation, and improvement. The controls are the body. The ISMS is the nervous system that makes them move.
A review restricted to policies establishes aspects of design. Remote inspection of reliable operating records can support an operating-effectiveness conclusion. State the limits of the supplied evidence and the claim it can support.
6.2 Physical and environmental security
Tessera runs on AWS, which buys them a tidy advantage: the physical security of the data centre is largely AWS’s problem, attested through AWS’s own certifications and the shared-responsibility split you learned in Chapter 5. Tessera does not secure the racks their instances live on. That does not leave them with nothing to secure.
They have a Perth office and staff laptops and phones that leave the building every evening. They may also have a small co-location rack for low-latency work, or a development box under someone’s desk that nobody documented. Physical controls (A.7.1 through A.7.14) ask the unglamorous questions that decide whether any of that matters: is the perimeter secured, is access controlled and logged, are visitors managed, is the server cupboard locked, is equipment protected against fire and flood and the cleaner who unplugs the router to plug in a vacuum cleaner.
The desk read gives you Tessera’s physical security policy, the badge-access procedure, the visitor-management process, the clear-desk and clear-screen standard, and the equipment-disposal procedure. Read together they describe an office that sounds disciplined. Badge access is “enforced 24/7.” Visitors “must sign in and be escorted.” Clear desk is “mandatory.” Media disposal “follows a certified destruction process.”
Notice the verbs. Enforced, must, mandatory, follows. Those are promises, and a promise is an assertion. From those policies alone you cannot confirm the badge reader at the side entrance actually denies a revoked card, that the visitor log carries a real signature for yesterday, that the fire-suppression system was serviced when the maintenance record claims, or that the back door near the loading bay is not propped open with a recycling bin every afternoon so the smokers can get back in. You have read what should happen. You have not seen what does.
6.3 HR security: the employment lifecycle
People controls are where organisations hurt themselves most predictably, because people are a lifecycle, not a state. A.6 makes that explicit. There is a moment a person joins, a long stretch in the middle where their role and access drift, and a moment they leave. Each transition is a control point, and the controls (A.6.1 screening, A.6.2 terms and conditions, A.6.3 awareness and training, A.6.5 responsibilities after termination or change, A.6.6 confidentiality agreements, and the rest) cluster around the joins.
Onboarding is the first gate. Screen candidates before employment, have terms signed before you grant access, put confidentiality agreements in place before the new starter sees customer data, and deliver security awareness training before they can do damage. The control objective is simple: nobody gets the keys before they have been checked and have agreed to the rules.
Role change is the silent one. A support engineer becomes an SRE and picks up production access. A developer moves into a team that handles payment data. Each move should trigger an access review, because the permissions that were correct last quarter may now be excessive. The work is invisible and has no deadline, and so it is exactly the control that quietly stops happening.
Offboarding is the one that ends up in breach reports. When someone leaves, the clock starts on every minute their access stays alive after their last day. Return of assets, revocation of logical and physical access, handover of responsibilities, a final reminder of confidentiality: the offboarding checklist (A.5.18 for access rights, A.6.5 for continuing responsibilities, and A.5.11 for return of assets) is short, well-understood, and routinely incomplete.
E03 supplies the revocation deadlines and E05 later supplies checklist-design facts. Do not infer complete credential coverage from the existence of a sign-off field. Request termination, ownership and disable records, and reconcile them. Those records can be inspected remotely; physical attendance is not required for the arithmetic.
6.4 Asset management
You cannot protect what you have not inventoried. Asset management is the unsexy foundation under most other controls, and in the 2022 standard it lives largely in the organizational family: the inventory of information and associated assets (A.5.9), acceptable use (A.5.10), return of assets (A.5.11), classification (A.5.12), and labelling (A.5.13).
The desk read gives you Tessera’s asset register and their classification scheme. The register should list the systems, the data stores, the devices, and the information that flows between them, each with an owner. The classification scheme should tell you which of that information is public, internal, confidential, or restricted, and what handling each tier demands.
An asset register can miss an unreturned laptop, an abandoned database or unclassified customer records. These are examples to investigate, not additional findings in the fixed case. The register alone cannot establish completeness. Compare it with reliable discovery, procurement and disposal records, recording any blind spots.
6.5 Suppliers and the cloud Tessera sits on
Tessera relies on cloud services, a payment processor and a hosted support model. Supplier oversight is part of its ISMS. A service agreement establishes obligations; appropriate independent assurance and Tessera’s own monitoring can support conclusions about performance.
Chapter 3 introduced the reliance worksheet. E09’s payment-report period ends before the assessment cutoff and includes an exception. E07’s AI-service bundle lacks executed processing terms. Do not assume all agreements are present merely because the supplier list exists.
For the support assistant, record the absent terms, uncertain regions and unverifiable training-setting screenshot. Request deployment-specific configuration and relevant vendor assurance. A public security page cannot establish actual handling of this account’s data. Equally, unavailable evidence does not prove a vendor misused it. Carry the assurance gap into the privacy assessment.
6.6 The ISMS itself: governance on paper
Everything above is a set of controls. The ISMS is the thing that is supposed to make them work as a system. ISO/IEC 27001 devotes Clauses 4 through 10 to it: the organisation defines its context (Clause 4), leadership commits (Clause 5), it plans the risk treatment that selects controls (Clause 6), it supports the system with resources, competence, awareness, communication, and documented information (Clause 7), it operates it (Clause 8), evaluates its performance (Clause 9), and improves it (Clause 10).
The artefact that ties the controls to the system is the Statement of Applicability (SoA), required by Clause 6.1.3. The SoA lists the controls Tessera has chosen, the justification for each inclusion and exclusion, and whether each control is implemented. It is the index of the whole control set, and at the end of Act I it is the single document you have spent the most time with.
E03’s SoA marks selected controls implemented without evidence references. Treat that status as an assertion needing support. The deadline conflict is already visible without operational access. Good formatting neither proves nor disproves control quality.
Ask what the particular document establishes. A policy can establish a requirement. A signed historical review can support operation for its population and date, subject to reliability checks. Neither supports an unrestricted conclusion about the whole ISMS. Record evidence type, scope and limits instead of declaring all documents either proof or worthless.
6.7 From documents to a preliminary opinion
A preliminary assessment should separate supported design observations, known design defects and operating questions that remain unanswered.
An illustrative summary of E03 says, “Offboarding operates within 24 hours because P-IT requires it.” The premise establishes a deadline, not compliance with it. It also overlooks P-HR’s two-hour rule. Correct the summary to name both criteria and request operating records. A model supplied with reliable logs could assist their analysis, but still needs verification.
🗂️ Tessera Case: Tessera’s preliminary readiness opinion
The selected design records identify an ISMS scope and control responsibilities. They do not establish whole-ISMS readiness. E03 contains conflicting revocation deadlines and unsupported implementation statuses. Operational evidence for revocation, scheduled reviews and recovery remains to be tested. Supplier reliance and the support assistant’s processing terms are unresolved.
We recommend completing the test programme and resolving the criteria conflict before making a Stage 2 recommendation. We have not assessed every requirement needed for Stage 1 or certification. This is a preliminary, limited-evidence readiness assessment.
That opinion identifies what the next phase must answer without assuming it will upgrade the result.
Time: 20 minutes. No AI required. Write your Act I assessment using E01–E03. For each claim, mark “supported design observation”, “design issue” or “operating evidence needed”. Include the conflicting deadlines and identify the next records to request. Avoid asserting whole-ISMS alignment from this selected extract.
6.8 The question, answered
Act I’s outcome is a mandate, a criteria map and a test programme, with a bounded preliminary assessment. Act II adds the operating records needed to test selected claims. It may confirm a control, expose a failure or leave a question unresolved.