Rebuilding a Stale Policy Framework Without Stopping the Plants
Stellar Components is a 5,000-employee manufacturer with 22 plants. Its Acceptable Use Policy is six years old, stored as a PDF on the intranet, and never reviewed. Internal audit found 38 unsanctioned SaaS applications, BYOD tablets issued by plant managers despite a policy ban on personal devices, and 47 open exceptions. Twelve exceptions were approved verbally by IT managers with no expiry or compensating controls. There is no policy owner, no training attestation, and no linkage between policies and controls. The new CIO wants a policy framework overhaul but cannot pause plant operations. The General Counsel wants to avoid a repeat audit finding, and the COO is worried that strict enforcement will block production. Plant managers say the tablets are needed for shift handover and maintenance checklists. The company has 90 days before the next audit committee meeting.
1. Diagnose the policy framework failures and propose a target policy architecture with owners, review cycles, and control mapping.
Read the worked answer
Diagnosis. The policy is a document, not a control system. It is stale, unowned, inaccessible in workflow, and disconnected from exceptions and training. The 38 unsanctioned SaaS apps and plant BYOD show that policy is not aligned with how work is done. Verbal exceptions with no expiry mean the real policy is whatever an IT manager allows.
Target architecture. Tier 1: board-approved security policy stating intent and risk appetite. Tier 2: standards for acceptable use, BYOD, cloud services, access control, and data handling. Tier 3: procedures for exception handling, SaaS approval, and device onboarding. Assign an owner for each document and a review cycle, annual or on material change. Map each policy to controls and audit evidence. Publish in a searchable location and require attestation at onboarding and annually. Establish a policy review board with security, legal, HR, operations, and plant representation. Keep plant procedures short and visual. The judgment is to reduce document volume and increase enforceability; a smaller set of owned, mapped policies is better than a comprehensive library nobody follows.
2. Design an exception process that handles the 47 existing exceptions and the plant BYOD use case without creating a new audit finding.
Read the worked answer
Exception process. Create a single intake form with risk rating, compensating controls, expiry date of no more than 12 months, and approver based on risk. Existing 47 exceptions: triage within 30 days; close duplicates, formalize verbal approvals in writing, and assign expiry. For plant tablets, do not simply grandfather them. Define a managed BYOD or corporate-owned standard: enrollment in mobile management, encryption, screen lock, remote wipe, segregated access to maintenance checklists, and no email or personal apps. If a tablet cannot meet the standard, restrict it to a local, low-risk use. Approve a time-bound exception for shift handover while the standard is implemented. The COO must own the operational risk. The judgment is to make the exception visible and temporary, not to win a policy argument with plant managers.
3. Define three metrics the audit committee should use to judge whether the policy program is improving.
Read the worked answer
Metrics. 1) Policy attestation rate by site and role, with a target of 95% and a breakdown for plants. 2) Percentage of exceptions with an owner, expiry, and compensating control, and the number past expiry. 3) Time to approve or reject a new SaaS or device request, plus the number of unsanctioned apps found in discovery. A fourth could be audit findings closed on time, but three is enough for the audit committee. Report trends quarterly. The judgment is to measure behavior and risk, not document counts. A policy program that reports 22 policies published tells the committee nothing; attestation, exception hygiene, and shadow IT discovery show whether the program is working.