janderscience-skills 0.0.0-stage → 1.0.0

package/sources/headcount/plugins/it-operations/.claude-plugin/plugin.json

@@ -0,0 +1,19 @@
+{
+  "name": "it-operations",
+  "description": "Corporate IT: service desk, systems and network administration, virtualization and cloud, telephony and conferencing, endpoints, assets, identity lifecycle, and backup and recovery.",
+  "version": "1.0.0",
+  "author": {
+    "name": "Chris Brock"
+  },
+  "repository": "https://github.com/cbrock84/headcount",
+  "keywords": [
+    "it-operations",
+    "service-desk",
+    "sysadmin",
+    "network",
+    "endpoint-management",
+    "virtualization",
+    "cloud",
+    "telephony"
+  ]
+}

package/sources/headcount/plugins/it-operations/.codex-plugin/plugin.json

@@ -0,0 +1,28 @@
+{
+  "name": "it-operations",
+  "version": "1.0.0",
+  "description": "Corporate IT: service desk, systems and network administration, virtualization and cloud, telephony and conferencing, endpoints, assets, identity lifecycle, and backup and recovery.",
+  "author": {
+    "name": "Chris Brock"
+  },
+  "repository": "https://github.com/cbrock84/headcount",
+  "license": "MIT",
+  "keywords": [
+    "it-operations",
+    "service-desk",
+    "sysadmin",
+    "network",
+    "endpoint-management",
+    "virtualization",
+    "cloud",
+    "telephony"
+  ],
+  "skills": "./skills/",
+  "interface": {
+    "displayName": "IT Operations",
+    "category": "Productivity",
+    "shortDescription": "IT Operations, as an installable department",
+    "longDescription": "Corporate IT: service desk, systems and network administration, virtualization and cloud, telephony and conferencing, endpoints, assets, identity lifecycle, and backup and recovery.",
+    "developerName": "Chris Brock"
+  }
+}

package/sources/headcount/plugins/it-operations/skills/backup-and-recovery/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: backup-and-recovery
+description: Protects and restores data — backup coverage and scope, retention, immutability against ransomware, and proving restores actually work. Use this to design a backup regime, verify restores, plan retention, protect backups from ransomware, or recover from data loss.
+---
+
+# Backup and recovery
+
+Nobody wants backups; they want restores. The distinction is not pedantic — organizations discover
+the difference during the only event that matters.
+
+Recovery objectives and which processes must survive are set by
+`operations:business-continuity-and-resilience`. This skill delivers against them.
+
+## Coverage is where it fails first
+
+Most backup gaps are things nobody thought to include: a database somebody stood up outside the
+standard process, configuration that only exists in a running system, data in a SaaS platform assumed
+to be the vendor's responsibility, or a developer's machine holding the only copy of something.
+
+Reconcile backup coverage against the asset register from
+`it-operations:it-asset-management` on a cadence and treat the difference as a finding. An untested
+assumption of coverage is the normal state of affairs.
+
+Note that SaaS providers protect against **their** failures, not against your deletion or a malicious
+insider. Read what the contract actually commits to, rather than what the marketing implies.
+
+## The 3-2-1 shape, and why the offline copy matters
+
+Three copies, two media or platforms, one off-site — and, since ransomware, **one immutable or
+offline**.
+
+Modern ransomware deliberately targets backups first, using the credentials it found on the way in.
+A backup system reachable with production credentials will be encrypted alongside production.
+Immutable storage or genuinely offline copies are what survive this, and it is the difference
+between an outage and an extinction event.
+
+## Retention is a policy decision, not a storage one
+
+Retention has to satisfy operational recovery, legal and regulatory obligations, and data protection
+requirements — which pull in opposite directions. Data protection law obliges deletion of personal
+data you no longer have a basis to keep, and indefinite backup retention conflicts with that
+directly. Settle it with `legal-risk:privacy-and-data-protection`.
+
+Know how you would satisfy a deletion request that touches backups, before one arrives.
+
+## Test restores, or you have nothing
+
+A backup job reporting success proves a file was written. It says nothing about whether the data is
+complete, uncorrupted, or restorable in a usable time.
+
+Test on a schedule, restore to a separate environment, and verify the application actually works on
+the restored data rather than that the bytes arrived. Record how long it took — that measurement is
+the only honest input to an RTO, and it is invariably longer than assumed.
+
+Test the full-scale case at least annually. Restoring one file proves the mechanism; restoring the
+system proves the plan.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Tooling
+
+Backup platforms: Veeam, Rubrik, Cohesity, Commvault, Acronis, and similar.
+
+SaaS data is the gap people miss. Microsoft 365, Google Workspace, and Salesforce retain
+for a short window and no longer; Veeam, Druva, AvePoint, Keepit, and similar cover it.
+
+The tool is not the control. An untested restore is not a backup, whatever the console
+reports.
+
+## Never
+
+- Report backup health from job success rather than tested restores.
+- Leave backups reachable with production credentials.
+- Set retention without reconciling legal obligation against deletion duty.
+- Quote an RTO you have not measured by actually restoring.

package/sources/headcount/plugins/it-operations/skills/backup-and-recovery/references/sources.md

@@ -0,0 +1,17 @@
+# Sources — `it-operations:backup-and-recovery`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## NIST SP 800-34: Contingency Planning Guide for Federal Information Systems
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final>
+
+**Authoritative for:** What recovery time and recovery point objectives formally mean, what a business impact analysis must contain, and which plan covers what — contingency, disaster recovery, continuity of operations.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/chief-information-officer/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: chief-information-officer
+description: The CIO's remit — running the technology the company works on, service quality, IT spend, and the boundary with product engineering. Use this to set IT priorities, decide what IT owns versus engineering, structure IT spend or an IT roadmap, judge whether to build, buy or outsource, or work out why IT is seen as a cost center rather than an enabler.
+---
+
+# Chief Information Officer
+
+The CIO runs the technology the company works *on*. The CTO runs the technology the company
+*sells*. Confusing the two is why IT ends up owning a product roadmap it cannot resource, or why
+engineering ends up running a help desk badly.
+
+## What this department owns
+
+The systems every employee depends on and nobody markets: identity, endpoints, network, corporate
+applications, the service desk, and the backup and restore path. Its output is measured in
+availability, time-to-resolution, and how little anyone has to think about it.
+
+- `it-operations:service-desk` — the front door, and the honest measure of whether any of this works
+- `it-operations:systems-administration` and `it-operations:network-administration` — the estate
+- `it-operations:endpoint-management` — the most exposed surface, because it leaves the building
+- `it-operations:identity-lifecycle-administration` — execution of joiner-mover-leaver
+- `it-operations:it-asset-management` — what you have, who has it, what it costs
+- `it-operations:backup-and-recovery` — the restore, tested rather than assumed
+- `it-operations:virtualization-operations` — the hypervisor layer the servers actually run on
+- `it-operations:cloud-administration` — the corporate cloud and SaaS estate, distinct from the product's
+- `it-operations:telephony-and-conferencing` — voice, rooms, and the obligations they carry
+- `it-operations:collaboration-platform-administration` — mail, chat, meetings and file sharing,
+  where most of the organization's unstructured data actually lives
+
+## The boundaries that cause arguments
+
+State them once, in writing, and the recurring turf disputes stop:
+
+- **Security sets policy; IT executes it.** `security:access-and-identity` decides what a role should
+  be entitled to; this department provisions it. `security:vulnerability-management` decides what is
+  urgent; `it-operations:systems-administration` runs the cadence.
+- **Engineering owns the product estate; IT owns the corporate estate.**
+  `technology:cloud-infrastructure` designs the environment the product runs in. Where a corporate
+  system runs in the same cloud, ownership follows who the users are, not where it is hosted.
+- **Continuity objectives are the business's; the restore is IT's.**
+  `operations:business-continuity-and-resilience` sets RTO and RPO with the process owners; this
+  department has to deliver against them and should say plainly when it cannot.
+
+## Build, buy, or outsource
+
+Default to buy for anything that is not a differentiator. Building an internal tool that a mature
+product already solves is a decision to maintain it forever, staffed by people who would rather be
+doing something else.
+
+Outsource where the work is commoditized and the failure is recoverable — first-line support out of
+hours, hardware logistics. Keep in-house what needs institutional context or carries irreversible
+risk: identity, data, and anything where a bad decision is discovered a year later.
+
+## The recovery you have never tested is a plan, not a capability
+
+Backups that have never been restored, failovers never exercised, and runbooks never followed under
+pressure are all assertions. The characteristic discovery during a real incident is that one of them
+was wrong in a way nobody could have known without trying.
+
+Test on a schedule, with the person who would actually do it rather than the one who designed it,
+and time the restore — recovery time is the number the business will ask for, and the only honest
+answer comes from having done it. The same logic applies to the communication plan: its first real
+exercise should not be its first real incident.
+
+## Spend, and the cost-center trap
+
+Attribute IT cost to the functions consuming it rather than reporting one aggregate. An
+undifferentiated IT budget invites across-the-board cuts, because nobody can see what any of it buys.
+
+The trap is real: a department judged only on cost is asked only to be cheaper, and the first
+casualties are refresh cycles and patching, which surface as incidents two years later with no
+visible cause. Report service outcomes alongside cost, and be specific about what a proposed cut
+removes.
+
+Track the split between running the estate and changing it, and defend it as a target rather than
+letting it be the residue after everything else. An estate consuming everything on keeping the
+lights on has no capacity to improve, and next year it will consume more — the ratio decays on its
+own unless someone holds it.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Accept a continuity objective you have not demonstrated you can meet.
+- Let identity policy and identity execution sit with the same reviewer.
+- Build an internal tool for a solved commodity problem.
+- Report IT cost without reporting what it delivered.
+- Count an untested restore as a recovery capability.

package/sources/headcount/plugins/it-operations/skills/chief-information-officer/references/sources.md

@@ -0,0 +1,17 @@
+# Sources — `it-operations:chief-information-officer`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## NIST SP 1800-5: IT Asset Management
+
+NIST / National Cybersecurity Center of Excellence · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/1800/5/final>
+
+**Authoritative for:** What an ITAM solution must be able to answer — which assets exist, who owns them, what software is running, whether it is licensed, and the discrepancy list that flags unmanaged devices as the primary security indicator.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/cloud-administration/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: cloud-administration
+description: Administers the cloud the company runs on rather than the one it sells — tenant and subscription structure, the SaaS estate and who owns each app, identity as the real perimeter, cloud spend that arrives as a surprise, and what the provider does not do for you. Use this to structure subscriptions or tenants, get control of sprawling SaaS, cut a cloud bill, work out who owns an application nobody admits to buying, or decide what corporate workloads belong in cloud at all.
+---
+
+# Cloud administration
+
+Corporate cloud is bought, not architected. Someone needed a tool, expensed it, and it entered the
+estate without a review, an owner, or an offboarding path. The characteristic failure is not a bad
+design — it is discovering the estate years later, one invoice at a time.
+
+This is the cloud the business runs on. For the cloud a product is built on — environments,
+infrastructure as code, scaling, region failure — see `technology:cloud-infrastructure`. The two
+follow different rules and the boundary is worth keeping sharp.
+
+## Structure the tenant before you need to
+
+Subscription and account structure encodes what you can later separate: billing, access, policy,
+and blast radius. Retrofitting it means moving live workloads, so the cheap moment is the first
+one.
+
+A workable default is to separate by what you would want to bill, govern, or lose independently —
+production corporate services, non-production, and anything with a distinct compliance obligation.
+Resist a subscription per team; teams reorganize, and the structure outlives them.
+
+Tag at creation with owner, cost center, and environment, and enforce it with policy rather than
+documentation. Untagged resources become unattributable spend within a quarter, and nobody
+volunteers to claim them.
+
+## The SaaS estate is the part nobody is managing
+
+Most companies underestimate their application count by a wide margin, because the ones they know
+about were bought by IT and the rest were bought by everyone else. The discovery methods that
+actually work are financial, not technical: expense reports, corporate card statements, and the
+identity provider's sign-in logs. Network monitoring finds less than the accounting system does.
+
+Every application needs a named business owner, a renewal date, and a data classification. Without
+the owner there is nobody to ask at renewal. Without the renewal date the negotiation happens after
+auto-renewal. Without the classification, nobody knows which breach notification obligations apply
+when the vendor is compromised.
+
+An application that stores customer or employee data belongs in the review that
+`legal-risk:privacy-and-data-protection` describes, and a departing employee's access to it is
+`it-operations:identity-lifecycle-administration`'s problem — which it cannot solve for an
+application it does not know exists.
+
+## Identity is the perimeter, so treat it as infrastructure
+
+Once the estate is cloud, network location protects nothing and the identity provider is the only
+consistent control point. Single sign-on is therefore not a convenience feature; it is what makes
+deprovisioning possible in one place instead of forty.
+
+The practical rule is to refuse applications that cannot federate, or to accept them knowingly with
+a documented manual offboarding step. Vendors that charge extra for SSO are charging for the
+security baseline, and that cost belongs in the purchase decision rather than being discovered
+later.
+
+Conditional access, MFA, and privileged role activation are the controls worth the effort. See
+`security:access-and-identity` for the design; this skill owns operating it across a real estate.
+
+## Cloud spend surprises are structural
+
+Cloud bills grow because nothing in the system stops them. Resources are easy to create, nobody is
+billed personally, and consumption is invisible until the invoice.
+
+Three habits catch most of it: a budget alert on every subscription before workloads land, a
+monthly review of the largest movers rather than the whole bill, and a scheduled look at anything
+running that nobody has logged into. Reserved and committed pricing is real money for steady
+workloads, but it is a bet on a run rate — commit only where the load is genuinely predictable.
+
+Non-production environments running overnight and at weekends are the most common single line of
+waste, and shutting them on a schedule is a change nobody notices.
+
+## Shared responsibility is narrower than people assume
+
+The provider keeps the platform available. Almost everything else — configuration, access, and in
+most cases the data itself — stays yours.
+
+The one that catches organizations out is backup. A major SaaS suite protects itself against its
+own failures, not against a user deleting a mailbox or a ransomware event propagating through
+sync. Retention settings are not backups, and the recycle bin is not a recovery point. Decide
+deliberately what needs independent protection under `it-operations:backup-and-recovery` rather
+than assuming the vendor's durability promise covers your mistakes.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Tooling
+
+Platforms: AWS, Microsoft Azure, Google Cloud, and similar.
+
+Infrastructure as code: Terraform, OpenTofu, Pulumi, Bicep, CloudFormation, and similar.
+
+Cost visibility: the native cost tools, or CloudZero, Vantage, Finout, and similar.
+Guardrails: AWS Control Tower, Azure Policy, Wiz, and similar.
+
+Console changes nobody can reproduce in code become the outage you cannot rebuild from.
+
+## Never
+
+- Buy an application that cannot federate without recording the manual offboarding step.
+- Let a resource exist without an owner tag and a cost center.
+- Treat vendor retention settings as a backup.
+- Structure subscriptions around the current org chart.

package/sources/headcount/plugins/it-operations/skills/cloud-administration/references/sources.md

@@ -0,0 +1,57 @@
+# Sources — `it-operations:cloud-administration`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## AWS Well-Architected Framework
+
+Amazon Web Services · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html>
+
+**Authoritative for:** What AWS itself considers a correct design on AWS, and therefore what an AWS architecture review will be graded against.
+
+## Azure Well-Architected Framework
+
+Microsoft · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://learn.microsoft.com/en-us/azure/well-architected/>
+
+**Authoritative for:** Microsoft's own normative design guidance for Azure, and the basis of its assessment tooling.
+
+## CIS Benchmarks
+
+Center for Internet Security · global · **account required — cite it; the user fetches it**
+
+<https://www.cisecurity.org/cis-benchmarks>
+
+**Authoritative for:** The consensus hardening baseline for a specific product version, with two profile levels. The non-defense equivalent of a STIG and the baseline most commercial audits cite.
+
+## Google Cloud Architecture Framework
+
+Google Cloud · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://cloud.google.com/architecture/framework>
+
+**Authoritative for:** Google Cloud's own normative design guidance, and what its architecture reviews assess against.
+
+## NIST SP 800-145: The NIST Definition of Cloud Computing
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/145/final>
+
+**Authoritative for:** What counts as infrastructure, platform or software as a service, and what public, private, community and hybrid mean. Still the definition contracts and audits cite.
+
+## NIST SP 800-207: Zero Trust Architecture
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/207/final>
+
+**Authoritative for:** What zero trust denotes — the policy engine, administrator and enforcement point model, and the tenets — so that a vendor cannot redefine the term mid-conversation.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/collaboration-platform-administration/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: collaboration-platform-administration
+description: Administers the email, chat, meeting and file-sharing platform the organization runs on — tenant and domain configuration, mail authentication and routing, phishing and spam controls, shared mailboxes and distribution groups, external sharing and guest access, permission sprawl in file storage, and retention and legal hold. Use this to configure a tenant, tighten sharing, investigate a mail delivery or phishing problem, or work out who can see a file and why.
+---
+
+# Collaboration platform administration
+
+This platform holds most of the organization's unstructured information and nearly all of its
+external communication. It is usually configured once during migration, by whoever ran the
+migration, and then never revisited.
+
+## Get mail authentication right, and keep it right
+
+SPF, DKIM and DMARC together determine whether your mail is delivered and whether someone else can
+send as you. All three need to exist and agree.
+
+- **SPF** breaks quietly as third-party senders accumulate — marketing platforms, ticketing systems,
+  invoicing tools — and has a hard limit on lookups that a growing list eventually crosses.
+- **DKIM** has to be enabled per sending domain and per service, not once for the tenant.
+- **DMARC** starts in monitoring and only protects once it moves to enforcement. A policy left at
+  none for two years is a report nobody reads.
+
+Every new tool that sends mail on your behalf is a change to this configuration. Route that through
+the same process as any other change, or the first sign will be a customer saying your invoices go
+to spam.
+
+## Phishing controls are configuration, not awareness training
+
+External sender warnings, impersonation and lookalike-domain protection, attachment and link
+inspection, and blocking auto-forwarding to external addresses are settings. Auto-forward rules in
+particular are the classic account-compromise persistence mechanism, and the account owner will not
+notice.
+
+Alert on inbox rule creation that forwards or deletes. It is one of the highest-signal detections
+available and it comes free with the platform.
+
+## Shared mailboxes, groups and the identities nobody owns
+
+Shared mailboxes, distribution lists and team channels accumulate faster than anything else in the
+tenant and are never cleaned up. Each needs a named owner and a review date, because a distribution
+list nobody owns eventually mails the whole company by accident, and a shared mailbox with stale
+access is a standing data exposure.
+
+Never leave a shared mailbox with a sign-in-capable account. It is an unmonitored identity with a
+password.
+
+## External sharing is where file storage leaks
+
+The defaults are usually more permissive than the organization would choose, and the settings sit
+at several levels — tenant, site, folder, individual link — with the most permissive winning.
+
+- **Anyone-with-the-link sharing** is the setting worth deciding on deliberately. If it is allowed,
+  it needs an expiry.
+- **Guest access** should expire and be reviewed. Guests from a project three years ago are still
+  guests.
+- **Permission inheritance is where sprawl comes from.** Someone grants access to a top-level
+  folder to solve one request, and it propagates everywhere below.
+
+Run a sharing report on a schedule. Nobody discovers over-sharing by browsing.
+
+## Retention and legal hold are configured in advance or not at all
+
+Retention policies decide what survives deletion and for how long, and they have to be set before
+the data you will need is deleted. Legal hold suspends deletion for named custodians and must be
+capable of being applied quickly.
+
+The platform's own recycle bins are not a retention policy and not a backup — the retention windows
+are short and administrator deletion can bypass them.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Add a service that sends mail as your domain without updating authentication records.
+- Leave DMARC in monitoring indefinitely and describe the domain as protected.
+- Allow anyone-with-the-link sharing with no expiry.
+- Treat the platform's recycle bin as either retention or backup.

package/sources/headcount/plugins/it-operations/skills/collaboration-platform-administration/references/sources.md

@@ -0,0 +1,17 @@
+# Sources — `it-operations:collaboration-platform-administration`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## Secure Cloud Business Applications (SCuBA)
+
+CISA · US · public domain (US government) — quote freely
+
+<https://www.cisa.gov/scuba>
+
+**Authoritative for:** The secure configuration baselines for Microsoft 365 and Google Workspace tenants, with the ScubaGear and ScubaGoggles automated assessment tools. What a collaboration platform administrator should harden to rather than relying on vendor defaults.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/endpoint-management/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: endpoint-management
+description: Manages laptops, desktops and mobile devices — enrollment, configuration, patching, software distribution, and lost or compromised devices. Use this to set up device management, standardize builds, roll out software or an OS upgrade, handle a lost device, or bring an unmanaged fleet under control.
+---
+
+# Endpoint management
+
+Endpoints are the most exposed and least controlled part of the estate: they leave the building, run
+arbitrary software, and are operated by people whose job is not IT.
+
+## Enrollment is the control point
+
+A device that never enrolled is a device with no patching, no encryption guarantee, and no remote
+wipe. Enrollment must be a precondition of access to company data, not a request made afterwards.
+
+Automate it from procurement so a device is enrolled before the user opens it. Manual enrollment as a
+post-delivery step is skipped exactly when the desk is busy.
+
+Handle personal devices as a deliberate policy decision, not an accident. If personal devices reach
+company data, either manage the work container or restrict what they can reach — and be explicit with
+people about what the organization can and cannot see on their own hardware, because ambiguity there
+destroys trust quickly.
+
+## A small number of standard builds
+
+Every additional build variant multiplies testing, support and failure modes. Converge on few, and
+handle exceptions by adding software to a standard build rather than by creating a new one.
+
+Enforce the security baseline through configuration policy rather than instruction: disk encryption
+on, screen lock, firewall, up-to-date agents. Anything relying on a user to configure it is
+configured on some devices.
+
+## Patch on a cadence with a deadline
+
+Endpoints patch worse than servers because they are off, asleep, or the user keeps deferring. Allow
+deferral with a hard deadline and force after it, and communicate the deadline in advance — an
+unexpected forced reboot during a customer call is what teaches people to avoid management.
+
+Report coverage as a percentage of the fleet, and specifically chase the long tail. The devices that
+never appear in patch reports are usually the interesting ones: traveling users, spares, and the
+machine in a cupboard still holding a domain account.
+
+## Lost, stolen, or leaving
+
+Have the sequence ready in advance: lock, locate if possible, wipe, revoke credentials and sessions,
+and record what data was on it for `legal-risk:privacy-and-data-protection` to assess notification.
+
+Encryption is what turns a lost laptop from an incident into paperwork. Verify enforcement
+continuously rather than trusting the policy is applied — the device where it silently failed is the
+one that gets left in a taxi.
+
+Departures are coordinated with `people:onboarding-and-offboarding`, with asset return tracked
+against `it-operations:it-asset-management`.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Tooling
+
+Windows: Microsoft Intune, Configuration Manager, Ivanti, and similar. Apple: Jamf Pro,
+Kandji, Mosyle, and similar. Cross-platform: NinjaOne, Automox, Addigy, and similar.
+
+Endpoint protection: Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, and
+similar.
+
+Pick for your fleet's majority and accept a second tool for the minority. One tool that
+half-manages both platforms costs more than two that each work.
+
+## Never
+
+- Allow company data onto a device that never enrolled.
+- Rely on users to apply security configuration.
+- Allow indefinite patch deferral.
+- Assume encryption is on without verifying it per device.

package/sources/headcount/plugins/it-operations/skills/endpoint-management/references/sources.md

@@ -0,0 +1,43 @@
+# Sources — `it-operations:endpoint-management`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## CIS Benchmarks
+
+Center for Internet Security · global · **account required — cite it; the user fetches it**
+
+<https://www.cisecurity.org/cis-benchmarks>
+
+**Authoritative for:** The consensus hardening baseline for a specific product version, with two profile levels. The non-defense equivalent of a STIG and the baseline most commercial audits cite.
+
+## NIST SP 800-124: Guidelines for Managing the Security of Mobile Devices
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/124/r2/final>
+
+**Authoritative for:** The baseline control set for mobile endpoints and the deployment-model distinctions — corporate-owned, personally enabled, bring-your-own — that mobile policy arguments turn on.
+
+## NIST SP 800-40: Guide to Enterprise Patch Management Planning
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/40/r4/final>
+
+**Authoritative for:** What a defensible patch program contains — maintenance windows, phased deployment, and the position that leaving something unpatched requires documented compensating controls rather than silence.
+
+## Security Technical Implementation Guides
+
+Defense Information Systems Agency, US Department of Defense · US · public domain (US government) — quote freely
+
+<https://public.cyber.mil/stigs/>
+
+Machine-readable: <https://public.cyber.mil/stigs/downloads/>
+
+**Authoritative for:** The exact required configuration of a given operating system, hypervisor or appliance, setting by setting with severity. When two administrators disagree about a hardening value, this states the required one.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.