Security Policy and Standards Development Questions

Direct answer
Set the minimum personal-device requirements by what the device can reach, not by its ownership, and limit the company's management to the work data and work apps on the device. Where the EU and US differ, build to the stricter employee-privacy expectation as the global baseline and add US-only options only where there is a business reason. This is a decision for Security, Legal, HR and employee representatives together; counsel decides what is lawful in each country.

Deciding minimum requirements (risk-based tiers)

1. Define what a personal device may access. For example: email and calendar only (low risk), internal applications (medium), regulated or customer data (not allowed on personal devices).
2. Set requirements per tier.
   | Access tier | Minimum requirements |
   |---|---|
   | Email and calendar | Current supported operating system, screen lock, device encryption, work apps in a managed container (a separate, company-controlled area of the phone holding work apps and data), ability to remove work data remotely |
   | Internal applications | All of the above plus device registration, no jailbreak or root (removing the manufacturer's built-in security restrictions, which lets malware bypass protections), patch within a set window |
   | Regulated or customer data | Company-owned managed device only |
3. Separate work from personal. Use a work profile or app-level management so the company controls the work container, not the whole device.

Reconciling inspection with privacy

• Manage the container, not the person. Remote wipe applies to work data only. No access to personal photos, messages, browsing history or location unless the employee is told and counsel has approved.
• Data minimisation and purpose limitation. Data minimisation means collecting only what is needed; purpose limitation means using data only for the purpose you stated. In the EU, the General Data Protection Regulation requires collecting only what is necessary for a stated purpose; inventory and security telemetry should be the minimum needed. Article 88 lets individual EU member states add their own more specific rules for employee data, including monitoring, so rules vary by country; in practice you ask counsel which national rules apply in each country where you have staff.
• Notice and agreement. A clear policy and acknowledgement. Consent has to be freely given, and an employee who worries that refusing will affect their job is not really free to say no, so employee consent is generally an unreliable basis. A legitimate-interest assessment is a documented test that weighs the company's need (protecting company data) against the employee's privacy and concludes the monitoring is justified and no more intrusive than necessary. Rely on that for monitoring rather than consent (counsel decides the basis).
• Assess the privacy impact of any monitoring (a data protection impact assessment, DPIA: a documented risk review required where processing is likely to be high-risk) and consult employee representatives (such as works councils, elected staff bodies that some countries require employers to consult before introducing monitoring tools) where local rules require it.
• US approach: typically more employer latitude, but state laws and expectations differ, so treat the EU level as the baseline for consistency.

Offer a choice
Employees who will not accept container management get a company-owned device or no access. That keeps the privacy position defensible.

What would change the call
If the business needs access to regulated data from phones, move to company-owned devices for that group rather than loosening BYOD rules.

Direct answer. Review every policy at least annually and on a defined event, whichever comes first. Frameworks do not fix one interval. ISO 27001 (the international standard for an information security management system) asks for review at planned intervals or if significant changes occur, NIST CSF 2.0 (the US National Institute of Standards and Technology's voluntary Cybersecurity Framework; GV.PO-02 is one of its Govern outcomes, a numbered statement of a result to achieve) asks that policy be reviewed and updated as requirements, threats, technology and mission change, and the HIPAA Security Rule (the US regulation protecting electronic health information) asks for periodic review in response to environmental or operational changes. Annual is a common default I would set, with event triggers overriding the calendar.

Cadence by layer. Policies: annually (they should be stable). Standards: annually, and whenever the technology they cover changes. Procedures: owned by process owners and updated when the process changes. Guidelines: as needed.

Triggers for an out-of-cycle update

• A significant incident or near miss (an event that could have caused harm but did not) that exposed a gap.
• A new or changed law, regulation, contract or customer requirement.
• A major technology or business change (new cloud platform, an acquisition, a new category of tool).
• New threat intelligence or an audit finding.
• A pattern of exceptions against one rule.

Review inputs. Threat intelligence, audit results, incident lessons, legal changes, exception data and adherence metrics. Approval: the policy owner drafts; a governance body (for example a policy committee: a small cross-functional group from security, legal, IT and HR that reviews and approves policy) reviews; the approver set by the policy hierarchy signs. Every version gets an ID, date, owner and change summary, and retired versions are archived rather than deleted. To avoid policy sprawl (too many overlapping documents) and contradictions, keep one owner per topic, a central inventory, and check new text against existing text before publishing.

Example where waiting would have been a mistake. Staff start pasting customer data into public generative-AI chat tools, and the acceptable-use policy says nothing. The next review is eight months away. Waiting leaves the gap open to a data leak. I would issue an interim directive (a short, time-limited instruction that has the force of policy until the full document is updated). Illustrative wording: "Interim Directive 2026-01, effective 12 October 2026: customer data, source code and credentials must not be entered into any generative AI tool that is not on the approved list. Expires 10 January 2027 unless incorporated into the Acceptable Use Policy. Approved by: CISO and General Counsel."

Pushing an urgent change without bypassing governance. Define an emergency path in the policy procedure itself: the CISO and legal approve an interim directive that takes effect immediately, time-boxed (for example 90 days), recorded in the register. The policy committee ratifies it (formally confirms it after the fact) at the next meeting or by asynchronous vote (members vote by email or a ballot tool over a set window instead of meeting). In the example: signed Monday 12 October, ratified by 26 October (14 days, illustrative), full policy revision approved before the 10 January 2027 expiry (90 days after issue). Governance is faster, not skipped.

Direct answer. Replace email with one system of record (the single authoritative place where the data lives: a ticketing workflow or GRC tool, where GRC means governance, risk and compliance) in which an exception is a record with an owner, an approver, an expiry date and a named compensating control. No record, no exception. An approval that cannot expire, cannot be queried and cannot be traced to a person is not an approval.

Key terms. An exception is a time-boxed, approved deviation from a policy or standard. A compensating control is an alternative safeguard that reduces the same risk when the required control cannot be met. Residual risk is the risk left after that safeguard.

Lifecycle (submission to closure)

1. Submit: requester files a form: which requirement, which systems, business reason, risk if unaddressed, proposed compensating control, requested end date, and a remediation plan with an owner.
2. Triage (security, within an agreed number of working days): rate residual risk using the company's risk scale (say Low, Medium, High, Critical: likelihood 1 to 5 x impact 1 to 5, with 1 to 4 Low, 5 to 9 Medium, 10 to 16 High, 20 to 25 Critical) and reject if a compliant option is cheap.
3. Approve by tier (below). The approval is recorded in the system, not in a thread.
4. Validate the compensating control before the exception goes live, not after.
5. Monitor: the control's evidence is collected on a schedule, and the record expires automatically.
6. Renew or close: renewal is a fresh request with the same approver tier or higher; closure requires evidence the requirement is now met.

Approval authority by tier (illustrative; adopt your own risk appetite, meaning the amount of risk leadership is willing to accept)

The person who bears the risk signs; security advises. The requester can never approve their own exception.

Deciding a workaround is adequate. Four tests: (1) it addresses the same threat the original control addressed, not a different one; (2) it is at least as strong in effect (a firewall rule restricting access to three named hosts can stand in for patching a legacy server only if exploit paths run through the network); (3) it is independently verifiable, meaning evidence exists a third party can check; (4) it is not already in place for another reason (an existing control cannot "compensate"). Then test it: run the detective check once before approval, and name who watches it. A detective check looks for a problem after the fact (a preventive control blocks it instead): for example a weekly report listing any connection to the legacy server from outside the three approved hosts.

Immutable audit trail. Every state change (who, what, when) is append-only and exportable; edits create new versions. This is what an auditor samples (picks a few records at random from) to test whether approvals really happened before the exception went live.

Worked ageing example (reporting date 5 Oct 2026, computed). EX-101 started 1 Jun for 90 days, expired 30 Aug: 36 days overdue. EX-102 started 15 Aug for 180 days, expires 11 Feb 2027: 129 days left. EX-103 started 1 Mar for 180 days, expired 28 Aug: 38 days overdue. Two of three are expired and still open, so the dashboard shows them red and escalates to their approvers.

Reporting

• Auditors: the full register export with approver, approval date, compensating control, evidence of its operation, and the expiry trail, so they can sample and trace.
• Executives (monthly, one page): open exceptions by tier, number overdue, oldest age, repeat exceptions (same requirement excepted twice or more, a sign the standard is wrong or the fix is underfunded: if five teams each request an exception to the same 30-day patch rule for the same legacy middleware, the rule is failing there), and count closed this period.

Trade-offs. Too much friction drives people back to email, so low tier should take minutes. Repeat exceptions should trigger a standard review, not endless renewals. Where the exception touches a regulated scope, counsel or the auditor decides whether a compensating control is acceptable to the framework.

A filled exception record (illustrative)

Direct answer
Fix it in two moves: first settle what "owner" means, then assign every policy exactly one named accountable role, with the approving body breaking any tie. An author writes the text, an approver authorises it to take effect, and the owner is accountable for the policy staying current and actually followed. Those are three jobs, often three different people.

Definitions (one line each)

• Policy: the short, board-or-executive-level statement of what the organisation requires.
• Owner: the one role that answers when the policy is stale, ignored or fails an audit. Owns review dates, exceptions and adoption.
• Author: drafts and edits. May be a security analyst or a lawyer; has no standing accountability after publication.
• Approver: the person or committee with authority to say "this binds the company" (for example the CISO, the chief information security officer, or a policy council, a standing group of senior leaders that approves policies). Approval should be independent of the owner where possible.

Steps to fix the audit finding

1. Inventory: list every policy with title, current owner, last review date, approver. Mark each as no owner, disputed owner, or clear.
2. Assign by rule, not by negotiation: the owner is the role that controls the risk or the resource the policy governs (for example, the head of IT operations owns the access control policy; HR owns the code of conduct). Where two teams both claim it, split the document if it covers two domains, otherwise the approving body decides in one meeting.
3. Record roles, not people: name the role (and the current holder) so that reorganisations do not recreate orphans.
4. Make it visible: a policy register with owner, approver, review date, and a quarterly report of policies without an owner or past review.
5. Backstop: any policy left unowned for a set period (say 30 days) defaults to the CISO's office until reassigned.

Worked example (illustrative numbers)
A set of 40 policies: 20 have no owner and 6 are claimed by both IT and Security. After the inventory, 14 of the 20 orphans map cleanly to one function. The remaining 6 disputed plus 6 hard orphans are 12 for the approving body to settle. Result: 40 of 40 owned, with a register showing each owner and review date.

Pitfalls

• Making Security the default owner of everything turns the policy set into a security-team document no one else follows.
• A shared "owned by the committee" entry is the same as no owner.
• Do not confuse a RACI table (a grid that gives each role on a task one of four labels: responsible, accountable, consulted or informed) with ownership: accountable must be exactly one.

Direct answer. "All sensitive data should be protected" cannot be enforced or tested: it does not define "sensitive", "protected", who is responsible, or what failing looks like, and "should" makes it optional. I would rewrite it as a mandatory statement with a defined scope, specific requirements, an owner and a way to check.

Rewrite

Policy statement DP-01. All data classified as Confidential or Restricted under the Data Classification Standard must be encrypted at rest and in transit using methods approved in the Cryptography Standard. Data owners are responsible for classifying their data and for confirming encryption is enabled. Systems that cannot meet this requirement must have an approved exception under the Exception Procedure. Compliance is verified quarterly through configuration scans and reported to the Security Governance Committee.

What I changed and why

Test of the result. An auditor can pick a sample of Confidential data stores and check encryption settings, and the pass or fail is clear. If a team cannot comply, there is a defined route.

What I deliberately left out. Algorithm names and key lengths belong in the standard, not the policy, so the policy does not go stale. I also avoided listing every control (backups, access, retention); those get their own statements.

Pitfall. Over-correcting into unreadable legalese. Keep the statement short enough that an employee understands what applies to them.