diff --git a/trust/controls/ai-data-controls.mdx b/trust/controls/ai-data-controls.mdx index ee4a80f..5c6152a 100644 --- a/trust/controls/ai-data-controls.mdx +++ b/trust/controls/ai-data-controls.mdx @@ -80,6 +80,19 @@ AI workflows use data needed for classification and analysis tasks. By default, | Network controls | Restrict outbound destinations to approved AI provider endpoints | | Auditability | Log AI request metadata and outcome events without exposing sensitive prompt text in operational logs | +## Model quality and oversight + +AI outputs are used as decision support and remain under human control for customer-impacting actions. + +| Area | Baseline approach | +|------|-------------------| +| Drift monitoring | Track output quality trends (for example classification consistency and recommendation usefulness) and review regressions after model/provider changes | +| Hallucination management | Constrain prompts to task-scoped context and require user validation before high-impact actions | +| Alerting | Monitor quality, error-rate, latency, and provider-failure signals through standard operational alerting paths | +| Remediation | Tune prompts/guardrails, roll back configuration/model changes, or switch provider paths when quality/risk thresholds are not met | +| Human oversight | Users can review, reject, edit, or override AI recommendations; autonomous high-impact execution is not the default model | +| Governance cadence | AI behavior and control effectiveness are reviewed as part of regular security and engineering control review cycles | + ## External references - [OpenAI data controls](https://platform.openai.com/docs/guides/your-data) diff --git a/trust/policies/change-and-network-rule-management-standard.mdx b/trust/policies/change-and-network-rule-management-standard.mdx new file mode 100644 index 0000000..6501447 --- /dev/null +++ b/trust/policies/change-and-network-rule-management-standard.mdx @@ -0,0 +1,59 @@ +--- +title: "Change and Network Rule Management Standard" +sidebarTitle: "Change & Rule Standard" +description: "Baseline for material change communication and firewall/network rule lifecycle controls." +icon: "git-branch-plus" +iconType: "duotone" +--- + +import { securityEmail } from '/snippets/variables.mdx'; + +Last reviewed: March 5, 2026 +Owner: Security + Engineering +Review cadence: Quarterly +Status: Implemented + +This standard defines how material platform changes are communicated and how firewall/network rules are requested, reviewed, approved, tested, and maintained. + +## What this standard answers + +- How customers are notified of material platform or schema changes +- Typical notice timing and notification channels +- How firewall/network rule changes are governed, including emergency changes + +## Material change notification baseline + +| Area | Baseline | +|------|----------| +| Triggering changes | Security, availability, data-handling, API/schema, or integration-impacting material changes | +| Notice channels | Email to designated customer contacts and agreed customer channels | +| Typical notice period | Advance notice aligned to contract or plan terms (commonly 15-30 days for planned material changes) | +| Emergency changes | Communicated as quickly as practical with impact and remediation context | + +## Notification content baseline + +- Change summary and reason for change +- Effective date and expected impact +- Required customer action (if any) +- Migration, mitigation, or rollback guidance where applicable + +## Firewall and network rule lifecycle + +| Phase | Baseline behavior | +|-------|-------------------| +| Request | Change request is documented and scoped to least privilege | +| Review | Security and engineering review for scope, exposure, and risk | +| Approval | Approval before production rollout | +| Validation | Rule behavior is tested/validated before full production use | +| Periodic review | Existing rules are reviewed for necessity and stale-entry cleanup | +| Emergency changes | Expedited implementation with retrospective review and remediation tracking | + +## Evidence map + +| Topic | Primary evidence | +|-------|------------------| +| Network controls and change validation | [Network Security](/trust/controls/network-security) | +| Incident handling and emergency comms | [Incident Response](/trust/controls/incident-response) | +| Assurance and reviewer workflow | [Compliance and Assurance](/trust/assurance/compliance-and-assurance), [Reviewer Map](/trust/reviewer-map) | + +Questions: [{securityEmail}](mailto:{securityEmail}) diff --git a/trust/policies/workforce-device-and-endpoint-security-standard.mdx b/trust/policies/workforce-device-and-endpoint-security-standard.mdx new file mode 100644 index 0000000..a01f621 --- /dev/null +++ b/trust/policies/workforce-device-and-endpoint-security-standard.mdx @@ -0,0 +1,56 @@ +--- +title: "Workforce Device and Endpoint Security Standard" +sidebarTitle: "Device & Endpoint Standard" +description: "BYOD and endpoint protection baseline for workforce access to company systems." +icon: "laptop-shield" +iconType: "duotone" +--- + +import { securityEmail } from '/snippets/variables.mdx'; + +Last reviewed: March 5, 2026 +Owner: Security + Engineering +Review cadence: Quarterly +Status: Implemented + +This standard defines minimum controls for workforce devices that access company systems, including personal-device (BYOD) and endpoint protection requirements. + +## What this standard answers + +- Whether BYOD is allowed and under what constraints +- Required endpoint security controls for company access +- How anti-malware and endpoint updates are managed + +## Device security baseline + +| Control area | Requirement | +|--------------|-------------| +| Device encryption | Full-disk encryption required | +| Authentication | Strong device unlock controls and MFA for company account access | +| Patching | Supported OS and security updates enabled | +| Endpoint protection | Centrally managed endpoint protection required for managed endpoints | +| Access restriction | Non-compliant endpoints can be restricted from privileged access paths | + +## BYOD baseline + +| Area | Requirement | +|------|-------------| +| BYOD eligibility | Allowed for approved use cases under security baseline controls | +| Required controls | Encryption, screen lock, patched OS, approved account security controls | +| Sensitive access | Production and privileged access paths remain restricted and least-privilege scoped | + +## Anti-malware management + +| Area | Baseline | +|------|----------| +| Engine/definitions | Vendor-managed automatic updates | +| Update frequency | Continuous/automatic based on provider update channels | +| Administration | Centrally managed policy baseline and monitoring for managed endpoints | + +## Evidence and enforcement + +- Access follows identity and role-based least privilege. +- Security exceptions require explicit approval and time-bound remediation. +- Additional policy evidence can be shared under NDA for enterprise review. + +Questions: [{securityEmail}](mailto:{securityEmail})