Boss Key Information Security Policy

1. Purpose

This policy defines the minimum security requirements Boss Key follows when designing, developing, deploying, and supporting software and agents for private-sector clients, including Microsoft 365-connected solutions.

2. Scope

• All Boss Key personnel, contractors, and subcontractors.
• All systems used to process client data.
• All client engagements involving development, deployment, support, or managed services.

3. Security Principles

• Apply least privilege and need-to-know access.
• Keep client production control in the client tenant/environment.
• Use secure-by-default architecture and change control.
• Maintain auditability of access, changes, and incidents.

4. Governance and Responsibility

• A named Boss Key Security Owner is responsible for this policy and annual review.
• Each engagement has a designated technical owner and incident contact.
• Clients retain responsibility for tenant-level approvals and admin consent in their Microsoft 365 tenant unless contractually delegated.

5. Identity and Access Management

• MFA is required for all privileged and client-facing accounts.
• Privileged access is limited, role-based, and time-bounded where feasible.
• Shared admin accounts are prohibited unless explicitly approved and logged.
• Access is revoked within 24 hours of role change or termination.

6. Client Tenant Access (M365/Entra)

• Boss Key requests only documented, minimum required API permissions.
• High-risk permissions require explicit written client approval.
• Client admin consent is required in the client tenant for production access.
• All consented permissions are recorded in an engagement permission register.

7. Data Protection

• Client data is classified at minimum as Public, Internal, Confidential, or Restricted.
• Confidential and Restricted data must be encrypted in transit and at rest.
• Production data is not copied to non-production environments without written approval and controls.
• Data retention and deletion follow contractual terms and applicable law.

8. Secrets and Key Management

• Secrets must never be hardcoded in source code or stored in plain text.
• Secrets are stored in approved secret managers or equivalent secure vaulting.
• Rotation intervals are defined per engagement; emergency rotation must be supported.
• Access to secrets is logged and restricted to authorized roles.

9. Secure Development and Change Management

• Source code uses version control with documented change history.
• Peer review is required for production-impacting changes.
• Dependencies are kept current and security patches prioritized by risk.
• Deployment must be reproducible and include rollback procedures.

10. Logging and Monitoring

• Security-relevant events are logged, including auth events, privilege changes, deployments, and data access events where feasible.
• Logs are protected from tampering and retained per contract and regulatory requirements.
• Alerts are configured for suspicious access, failed auth spikes, and critical system failures.

11. Incident Response

• Security incidents are triaged immediately and documented.
• Clients are notified per contractual breach and incident notification terms.
• Boss Key performs containment, eradication, and recovery actions with traceable records.
• Post-incident review and corrective actions are required.

12. Business Continuity

• Critical systems and configuration are backed up according to engagement RTO and RPO targets.
• Recovery steps are documented and tested periodically.
• Minimum continuity contacts are maintained for each active client engagement.

13. Third-Party and Subprocessor Management

• Third-party tools and services are risk-reviewed before use with client data.
• Subprocessors are disclosed where required by contract or law.
• Contracts include confidentiality and security obligations appropriate to data risk.

14. Personnel Security and Awareness

• Personnel with client access sign confidentiality obligations (NDA or equivalent).
• Security awareness training is completed at onboarding and annually.
• Policy violations may result in access removal and disciplinary action.

15. Compliance, Exceptions, and Review

• Exceptions require documented risk acceptance and approval by the Boss Key Security Owner and client where applicable.
• This policy is reviewed at least annually or after major incidents or regulatory changes.
• Evidence of compliance is maintained for audit and readiness purposes.

Appendix A: Minimum Engagement Control Checklist

• Architecture and data flow diagram.
• Permission matrix showing requested versus approved scopes.
• Asset inventory for systems and services handling client data.
• Incident contact and notification workflow.
• Backup, recovery, and rollback procedures.
• Access and offboarding register.
• Legal package: NDA, MSA/SOW, and DPA where applicable.

Appendix B: Client Shared Responsibility Statement

Unless otherwise contracted:

• Boss Key: Secure development, secure deployment process, support operations, and incident handling.
• Client: Tenant admin governance, consent approval, internal user and device controls, and business risk policy decisions.