{"description":"Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.","edges":[{"id":"e-review-provider-logs-and-monitor-activity-classify-monitoring-disposition","label":"Reports received","source":"review-provider-logs-and-monitor-activity","target":"classify-monitoring-disposition","whenValue":"reports_received"},{"id":"e-review-provider-logs-and-monitor-activity-escalate-provider-reporting-gap","label":"Reports missing","source":"review-provider-logs-and-monitor-activity","target":"escalate-provider-reporting-gap","whenValue":"reports_missing_escalate"},{"id":"e-escalate-provider-reporting-gap-classify-monitoring-disposition","source":"escalate-provider-reporting-gap","target":"classify-monitoring-disposition"},{"id":"e-classify-monitoring-disposition-log-remediation-actions","label":"Deviations","source":"classify-monitoring-disposition","target":"log-remediation-actions","whenValue":"deviations_identified"},{"id":"e-classify-monitoring-disposition-close-and-archive","label":"Conforming","source":"classify-monitoring-disposition","target":"close-and-archive","whenValue":"conforming"},{"id":"e-log-remediation-actions-close-and-archive","source":"log-remediation-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-LOG-08","UC-LOG-09"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-network-provider-service-monitoring","contentDigest":"sha256:214e4d9ded1ce0a8d5e2e038114d15720fb5a06388182a17d44245436b674619","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:214e4d9ded1ce0a8d5e2e038114d15720fb5a06388182a17d44245436b674619","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-network-provider-service-monitoring"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-network-provider-service-monitoring","source":"coworkcanvas-gallery","standards":["iso-27001","nist-csf-2","nist-800-53"],"teams":["it","procurement"]},"name":"Network & Provider Service Monitoring","nodes":[{"data":{"decisionField":"provider_reporting_status","description":"Agent reconciles each provider's monitoring requirements against its current contract and reviews the logs and reports delivered against them; human decides whether provider reporting was received and conforming","formData":{"fields":[{"key":"provider_reporting_status","label":"Provider Reporting Status","options":[{"label":"Reports received, review complete","value":"reports_received"},{"label":"Reports missing, escalate","value":"reports_missing_escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Establish what each external service provider must be monitored against under its current contract, review the activity, service status, and security-relevant events it reported this cycle against those obligations, and decide whether provider reporting was received and conforming. The network services manager owns this call.\n\n**Inputs**\n- The provider register — Vendor items for every provider delivering a network or network-adjacent service (`Vendor.category`, `tier`, `data_classification`, `business_owner`, `risk_owner`, `reassessment_cadence`, `monitoring_status`, `contract_end_date`). This is the register; there is no separate \"Provider\" type.\n- Current contracts and service agreements for each provider — uploaded at this step (PBC/external).\n- The previously tracked monitoring requirements per provider — the monitoring-requirements register document attached to this step on the previous instance — to diff against.\n- Each provider's logs and reports due this cycle — uploaded at this step (PBC/external).\n\n**Procedure**\n_Items 1–8 are agent-run (items 1–4 folded from the former \"Confirm provider monitoring requirements\" step); the human moment is the branch call in item 9._\n1. For each provider, extract the monitoring-relevant obligations from its current contract: committed service levels, security requirements, the cadence and format of the logs and reports the provider must deliver, and the provider's duty to notify security-relevant events.\n2. Diff the extracted obligations against the currently tracked monitoring requirements. Flag any provider whose contract was renewed, amended, or lapsed since requirements were last confirmed — a changed clause silently invalidates the old monitoring expectation.\n3. For each provider, record the concrete artifacts due this cycle (e.g., monthly SOC report, uptime attestation, security-event log export) and the date each is expected, so delivery can be tested below.\n4. Where a contract is silent on a monitoring obligation that should exist, note the gap for contractual follow-up rather than inventing an unenforceable requirement; compile the updated provider monitoring-requirements register and refresh the Vendor fields the contract review touched.\n5. Against that confirmed register and the provider Vendor register, review each provider's logs and reports due this cycle and mark delivered vs. not delivered on the defined cadence.\n6. For every received artifact, check the provider's activity, service status, and any security-relevant events against the contractual obligations; note each contractual breach or anomaly as a deviation with evidence.\n7. Confirm any provider-reported security event has, or needs, its own incident case rather than being tracked only here (coach-workflow-scan), so incident response is not silently owned by this monitoring cycle.\n8. Draft the provider-monitoring summary listing each provider's reporting status and conformance result (coach-document-upload).\n9. Pick the branch against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- Pick **reports_received** (\"Reports received, review complete\") when every in-scope provider delivered the logs and reports due on its defined cadence, each was reviewed against the confirmed monitoring requirements, and any contractual breach or anomaly found is already captured as a deviation with evidence.\n- Pick **reports_missing_escalate** (\"Reports missing, escalate\") when one or more providers failed to deliver a required log or report this cycle, so the reporting gap itself must be formally escalated and logged before disposition.\n- Note: a provider that delivered reports but shows a service-level or security breach is not a missing-reports case — that is a captured deviation and still routes through **reports_received**. Only non-delivery of a required artifact triggers escalation.\n\n**Record in AssureSwarm**\n- Submit the `provider_reporting_status` SELECT with the chosen branch; write the evidence references and reasoning in the step result and the approver in the step's approver record.\n- Item field update — for each provider's Vendor item, refresh the native fields the contract review touched via coach-item-update: `Vendor.monitoring_status` (enrolled once monitoring requirements are confirmed), `Vendor.reassessment_cadence`, `Vendor.next_reassessment_date`, and `Vendor.contract_end_date`.\n- Step document — attach the updated provider monitoring-requirements register (reporting cadence, expected artifacts and their due dates, the detailed committed service levels and security requirements, and any contract-silent gap noted for follow-up — none of which has a native Vendor field) and the provider-monitoring summary (coach-document-upload).\n\n**Exit criteria** — Every in-scope provider has confirmed monitoring requirements matching its current contract, with expected artifacts and due dates recorded; each due artifact is marked delivered or not delivered; the SELECT is submitted with a rationale citing which providers delivered and which did not; the unchosen branch is prunable.","kind":"decision","label":"Review provider logs and monitor activity","performedBy":{"primitives":["coach-query-data","coach-workflow-scan","coach-document-upload","coach-item-update"]}},"id":"review-provider-logs-and-monitor-activity"},{"data":{"description":"Agent drafts and sends a formal reporting-gap notice to the non-conforming provider and tracks the response; human confirms escalation was issued and logs the gap as a deviation","instructions":"**Objective** — Formally escalate to every provider that failed to deliver its contractually required logs or reports so the reporting gap is treated as a tracked deviation and does not silently break the monitoring cycle.\n\n**Inputs**\n- The provider-monitoring summary and the confirmed monitoring-requirements register identifying which artifacts are missing and the contractual clause requiring each.\n- Provider relationship-owner and provider-contact details.\n\n**Procedure**\n1. For each non-conforming provider, identify the specific missing artifact and cite the exact contractual clause that requires it and the cadence it breached.\n2. Draft a formal reporting-gap notice to each provider's correct contact: the obligation, the missing artifact, the period covered, and a required delivery date.\n3. Create a tracked escalation Issue for each gap (coach-item-create) and link it to the provider's Vendor item and the anchor Control (coach-items-link) so the gap is traceable end to end.\n4. Set a follow-up date for each escalation and record the interim risk of operating without the missing evidence this cycle.\n\n**Record in AssureSwarm**\n- Item create — one Issue per reporting gap: `issue_type: finding` (or `deficiency` where the non-delivery breaches a control obligation), `source: management_identified`, `severity`, `issue_owner` (the provider relationship owner), `identified_date`, `target_remediation_date` (the required delivery date), and `root_cause` = non-delivery of the contracted artifact (coach-item-create).\n- Item relationship — link each Issue to the provider's Vendor item and to the anchor Control (coach-items-link), so the reporting gap sits in the same single owned remediation log as every other deviation.\n- Step document — attach the reporting-gap notices and the tracking record to this step (coach-document-upload).\n\n**Exit criteria** — Every missing artifact has an escalation issued to the correct provider contact with a follow-up date; each reporting gap is logged as a deviation; the network services manager has confirmed the escalations before the cycle proceeds to disposition.","label":"Escalate provider reporting gap","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"escalate-provider-reporting-gap"},{"data":{"decisionField":"monitoring_disposition","description":"Judge device baseline and authorized changes, delivered service materiality and protected identity-preserving audit exchange across the full finding set.","formData":{"fields":[{"key":"monitoring_disposition","label":"Monitoring Disposition","options":[{"label":"Conforming, no deviations","value":"conforming"},{"label":"Deviations identified","value":"deviations_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge device baseline and authorized changes, delivered service materiality and protected identity-preserving audit exchange across the full finding set.\n\n**Inputs**\n- The anchor Control item — the network & provider monitoring control (UC-LOG-08/09) this monthly instance is attached to; read its prior open remediation Issues so already-tracked device findings are not re-raised.\n- Network device inventory (routers, switches, firewalls, load balancers, VPN concentrators, wireless controllers) with current running and startup configurations — uploaded at this step (PBC/external). There is no native Device/Asset item type in the Studio schema, so the inventory and configuration snapshots live as step documents, not items.\n- The approved hardening baseline for each device class (CIS Benchmark or the org's build standard), uploaded at this step: unused services/ports disabled, current patch/firmware level, administrative access restricted to named accounts and jump hosts, logging and NTP enabled, management-plane protections in place.\n- The change-control record and per-device change history (change tickets and approvals) — uploaded at this step as a change-ticket extract (CSV/XLSX). This cycle runs on its own monthly cadence — no upstream workflow feeds it.\n- The network service catalog listing every network and network-adjacent service, with an in/out flag for internally operated vs. outsourced or provider-delivered — uploaded at this step (PBC/external). The Studio schema has no Network Service item type, so the catalog lives as a step document, not items; outsourced services correspond to Vendor items in the register reviewed by *Review provider logs and monitor activity*.\n- Current service agreements, SLAs, and provider contracts for each service — uploaded at this step.\n- The prior cycle's documentation set — the service-documentation document attached to this step on the previous instance — to diff against for changes.\n- Delivered-service telemetry for the period: uptime/availability, latency and throughput metrics, incident/outage records, and security-control status (patching, certificate validity, config compliance) per service.\n- The anchor Control item (UC-LOG-08/09) this instance runs on, and the provider register — the Vendor items whose services exchange audit information.\n- The cross-organizational audit-exchange agreements per provider — uploaded at this step (PBC/external): the exchange method, the protection controls (encryption, access restriction, integrity protection), and each provider's audit point of contact.\n- A sample of recently exchanged audit records from each provider covering the period — uploaded at this step.\n- The upstream findings: the device-hardening exception list, the service documentation and conformance summaries, and the provider-monitoring summary with any reporting-gap escalations.\n\n**Procedure**\n_This checkpoint absorbs “Verify network device hardening”, “Monitor service conformance and flag deviations”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Verify network device hardening: Pull each in-scope device's current configuration and compare it line-by-line to its approved hardening baseline. Flag every drift: an enabled service or open port not on the baseline, a firmware/patch level behind the approved release, an unrestricted management interface, or logging/NTP disabled.\n2. Confirm patch currency against the vendor's current advisories; treat any device more than one maintenance release behind, or exposed to a known-exploited CVE, as a high-severity exception.\n3. Cross-reference each configuration change in the device change history against the change-control record. Any change without a matching authorized ticket is an unauthorized-change exception — capture the device, the change, and when it appeared.\n4. For each exception, name the responsible device owner and assign a preliminary severity (high = exploitable or unauthorized-access exposure; medium = baseline drift with a compensating control; low = cosmetic or documentation-only).\n5. Draft the hardening-verification summary: devices checked, count conforming, and the exception list with owner and severity for each.\n6. Monitor service conformance and flag deviations: For each service, reconcile three documented facets against the latest contract or internal service agreement: (a) security features (encryption in transit, authentication method, segmentation, DDoS/filtering protections), (b) committed service levels (availability %, latency, throughput, support response), and (c) management responsibilities (who administers, who monitors, who is accountable — the RACI).\n7. Flag any service whose documentation is stale (contract renewed or changed since last update), missing (a newly onboarded service with no entry), or contradicted (a documented level that differs from the signed SLA).\n8. For outsourced services, verify the documentation explicitly states which security responsibilities sit with the provider vs. retained in-house — an unassigned responsibility is a gap, not a default.\n9. For newly onboarded or changed services, draft the missing or updated entries covering all three facets, then compile the refreshed service-documentation set with a short change note listing what moved since last cycle.\n10. For each in-scope service, pull the period's delivered metrics and compute conformance against those documented commitments: availability vs. the committed SLA %, latency/throughput vs. threshold, and security-feature status (is each documented control present and effective?).\n11. Classify each non-conforming service by deviation type: security-feature gap (a documented control absent or failed), service-level breach (a metric below the committed threshold), or undocumented change (delivered behaviour differs from documentation with no change record).\n12. Attach the supporting evidence for every deviation — the metric extract, the outage window, or the failed-control record — so each is defensible without re-querying.\n13. Quantify materiality: for an availability breach, record the delta and duration; for a security gap, record the exposure and any compensating control.\n14. Draft the conformance summary: per-service conformance result, the deviation list with type and evidence, and a period-over-period trend where prior data exists.\n15. Network services manager: assess each deviation — is the assigned type right, is the recorded exposure the real one, and does the named compensating control genuinely reduce it — and settle which deviations carry into the disposition and at what materiality.\n16. Classify monitoring disposition: For each provider that exchanges audit information, confirm the exchange method actually used matches the agreed method and that the required protection controls were applied (records encrypted in transit and at rest, access restricted, integrity verifiable).\n17. Pull a sample of exchanged audit records and verify completeness and integrity — no truncation, timestamps intact, no evidence of tampering.\n18. Trace a sample of cross-organizational actions end to end through the exchanged records: confirm the originating user or service identity survives the handoff so a specific actor is still identifiable on the provider side. A trace where identity collapses to a shared or service account with no attribution is an identity-context failure.\n19. Record any exchange method that failed or any trace where identity context was lost, with the affected provider and records, and draft the audit-exchange verification summary.\n20. Consolidate all findings into one set (coach-query-data): device-hardening exceptions, service-conformance deviations, provider reporting and conformance findings, and the audit-exchange failures from items 16–19.\n21. Build a monitoring-disposition dashboard (coach-dashboard-create) showing each finding against its source (device / internal service / provider / audit exchange), owner, and severity, with trend against prior cycles.\n22. Reconcile the dashboard row count against each source step's exception list to confirm no finding was dropped between checkpoints.\n23. Draft the disposition summary (coach-document-upload).\n24. Classify the cycle against the criteria below and submit the SELECT.\n\n**Decision criteria**\n- Pick **conforming** (\"Conforming, no deviations\") only when the device-hardening check produced no open exception, every service met its documented security features and service levels, every provider delivered conforming reports, and cross-organizational audit exchange functioned with identity context intact.\n- Pick **deviations_identified** (\"Deviations identified\") when any of these exists: a device-hardening exception, a service-level breach or security-feature gap, a provider non-conformance or reporting gap, or an audit-exchange or identity-context failure. A single open finding of any type routes here.\n\n**Record in AssureSwarm**\n- Step document — attach the device-hardening verification summary and exception list (XLSX/PDF) to this step (coach-document-upload). Because the schema has no Device/Asset item type, this exception list IS the per-device record: one row per device with baseline-conformance result, patch status, unauthorized-change flag, owner, and severity — there is no item field to write these to.\n- Item read only — use coach-query-data to read the anchor Control and its open remediation Issues for context; do not attempt a per-device item write (no such type exists).\n- Step document — attach the refreshed network-service documentation set with its change note, and the service conformance summary with the deviation list (per-service conformance result, deviation type, materiality, and supporting evidence reference), to this step (coach-document-upload). With no Network Service item type these documents are the system of record: the security-features, service-level and management-responsibility (RACI) facets are structured sections of the documentation set, and per-service conformance results are columns in the summary — there are no item fields to write them to.\n- The deviations recorded here are raised as Issue items linked to the anchor Control by *Log remediation actions*.\n- Submit the `monitoring_disposition` SELECT with the chosen branch; write the evidence references in the step result and the approver in the step's approver record.\n- Step document — attach the audit-exchange verification summary (exchange-method conformance and the identity-context-preserved result are recorded per provider as columns here; neither has a native Vendor field) together with the disposition summary and dashboard link (coach-document-upload). Any failed exchange or lost-identity trace is raised as an Issue linked to the anchor Control by *Log remediation actions*.\n\n**Exit criteria**\n- Every in-scope device has a recorded baseline-conformance result; each exception carries an owner and severity; the network services manager has confirmed whether all devices remain hardened and controlled or named those needing immediate remediation.\n- Every service has current documented security features, service levels, and a named management owner, with outsourced services correctly splitting provider vs. in-house responsibility; every in-scope service has a conformance result; each deviation carries a type, a materiality assessment, and supporting evidence signed off by the network services manager before it feeds the disposition decision.\n- Each provider's audit-exchange method is confirmed functional or flagged, and cross-organizational actions are confirmed traceable to an identity or the failure is recorded as a deviation; the SELECT is submitted with a rationale referencing the consolidated findings set; the unchosen branch is prunable.","kind":"decision","label":"Classify monitoring disposition","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-dashboard-create"]}},"id":"classify-monitoring-disposition"},{"data":{"description":"Agent converts every deviation, regardless of source, into an owned item in the single remediation log; human confirms every deviation is owned, dated, and tracked","instructions":"**Objective** — Feed every deviation — from internal network devices or services, or from provider service commitments — into the single remediation log owned by this program, so nothing is remediated informally outside the tracked record.\n\n**Inputs**\n- The disposition summary and consolidated findings set from *Classify monitoring disposition*, each finding tagged with its source and severity.\n- The single program remediation log — the set of open Issue items linked to the anchor Control — and the roster of accountable owners (network administrators for internal findings; provider relationship owners, from the provider's `Vendor.risk_owner`/`business_owner`, for provider findings).\n\n**Procedure**\n1. Parse the disposition summary into a flat list of deviations, each with its source (device hardening, service documentation, service conformance, provider conformance, provider reporting gap, or audit-exchange failure) and root cause.\n2. Create one remediation-log Issue per deviation (coach-item-create), regardless of internal or provider origin, capturing owner, due date, severity, root cause, and interim mitigation; link each to the anchor Control (coach-items-link).\n3. Route provider-caused deviations to the accountable relationship owner for contractual follow-up (and link the Issue to the provider's Vendor item); route internal deviations to the responsible network administrator.\n4. Flag any deviation that recurs from a prior cycle and escalate it — a repeat finding signals the earlier fix failed or was never applied.\n5. Compile the consolidated remediation log for review.\n\n**Record in AssureSwarm**\n- Item create — one Issue per deviation: `issue_type: deficiency` (or `observation` for low-severity, documentation-only findings), `source: compliance_review`, `severity`, `issue_owner`, `identified_date`, `target_remediation_date`, `root_cause`, and `remediation_plan` (coach-item-create).\n- Item relationship — link every Issue to the anchor Control, and provider-caused Issues additionally to the provider's Vendor item (coach-items-link). This Control↔Issue link-set IS the single owned remediation log — carried-forward deviations are simply Issues still open when next month's cycle starts.\n- Step document — attach the consolidated remediation log (XLSX) to this step (coach-document-upload).\n\n**Exit criteria** — Every deviation, internal or provider, has a named owner and due date in the single remediation log; recurring deviations are escalated; the network services manager has confirmed the log before closure.","label":"Log remediation actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-remediation-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record for the cycle: hardening summary, service documentation and conformance summaries, provider-monitoring summary and any escalations, audit-exchange summary, disposition, and remediation log.\n- The designated evidence repository and its retention controls; next month's schedule.\n\n**Procedure**\n1. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls; record the archive location and reference.\n2. Leave open remediation-log Issues and pending provider-escalation Issues linked to the anchor Control — they persist across the cycle boundary as-is and are the carry-forward mechanism; only create a new Issue where a closure obligation was not already raised (coach-item-create), linking it to the anchor Control (coach-items-link). Record the next scheduled documentation refresh as a dated note in the closure record — the schema has no task/reminder type to hold it.\n3. Update the control execution log with the cycle result, conformance rate, and open-deviation count, and confirm next month's review is scheduled.\n4. Attach the closure record (coach-document-upload).\n\n**Record in AssureSwarm**\n- Workflow instance — this completed run is the cycle's audit trail; export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention.\n- Item relationship — open remediation and escalation Issues remain linked to the anchor Control as next month's carry-forward inputs; create and link any missing closure Issue (coach-item-create, coach-items-link).\n- Step document — attach the closure record (with the next-refresh reminder note) to this step (coach-document-upload).\n\n**Exit criteria** — The archived record is immutable and retrievable; every open item has a tracked owner and carry-forward link; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-network-provider-service-monitoring"}