Secure Development Policy

This Secure Development Policy ("Policy") describes security requirements for the software development lifecycle of MiseCentral LLC's ("MiseCentral," "we," "us," or "our") Services and related components. This Policy applies to MiseCentral engineering personnel, contractors contributing to production code, and quality assurance processes.

1. Purpose and Scope

1.1. Purpose. MiseCentral integrates security into design, implementation, testing, deployment, and maintenance of the Services to protect Customer Data, Operational Evidence, and platform integrity.

1.2. Scope. This Policy covers:

(a) application code for the hosted Services, including Adaptive Operational Intelligence, Work Intelligence, scheduling, work execution, Support Mode, Partner Support Mode, Connected Services governance, and Marketplace features;

(b) infrastructure-as-code and deployment automation for production environments;

(c) internal tools with access to production data; and

(d) third-party libraries and dependencies incorporated into the Services.

2. Secure Development Principles

2.1. Security by Design. Security requirements are identified during design and architecture review for features affecting authentication, authorization, data handling, integrations, audit logging, and privileged assistance workflows.

2.2. Least Privilege in Code. Services request only the permissions and data necessary. Cross-tenant queries and bulk exports require explicit authorization layers and auditing.

2.3. Defense in Depth. Input validation, output encoding, parameterized queries, CSRF protections for state-changing operations, and rate limiting are applied according to context.

2.4. Secure Defaults. Security-sensitive settings default to restrictive configurations. Customers may loosen certain controls through documented administration settings.

2.5. No Silent Impersonation. Development and review processes must preserve the Support Mode and Partner Support Mode model: assistance is attributable, ticket-linked, and customer-visible; impersonation flags remain false on session representations.

2.6. Advisory AI Outputs. Features generating Operational Recommendations, including Company Brain outputs, are implemented with clear advisory labeling, audit history, and without autonomous execution of irreversible operational actions unless explicitly configured and authorized by Customer workflow design.

3. Development Lifecycle Controls

3.1. Version Control. Production code resides in access-controlled version control with attributable commits and protected mainline branches.

3.2. Code Review. Material changes require peer review focusing on security, authorization, data handling, and regression risk before merge to production-bound branches.

3.3. Environment Separation. Development, staging, and production environments are logically separated. Production Customer Data is not used in non-production environments except in controlled, minimized datasets with appropriate authorization.

3.4. Secrets Management. Secrets, API keys, and credentials are not committed to version control. Production secrets are stored in dedicated secrets management systems with access logging.

3.5. Change Management. Production deployments follow documented procedures including rollback capability, release notes for security-relevant changes, and post-deployment monitoring.

4. Application Security Requirements

4.1. Authentication and Session Management. Implementation follows the Authentication Policy and MFA Policy, including organization MFA enforcement, platform Support Mode MFA, and secure session handling.

4.2. Authorization. Role-based and permission-based checks enforce tenant isolation, Partner delegation scope, staff platform capabilities, and seat licensing constraints at API and UI layers.

4.3. Input Validation. External input from users, API Clients, Connected Services, and webhooks is validated and sanitized to prevent injection, traversal, and logic abuse.

4.4. Cryptography. Industry-standard algorithms and libraries protect data in transit and at rest. Custom cryptography is avoided except where required by standards and reviewed by qualified personnel.

4.5. Error Handling. Error responses avoid exposing sensitive stack traces, internal identifiers, or cross-tenant information to end users.

4.6. Audit Logging. Security-relevant events, Support Mode mutations, Partner Support Mode actions, role changes, and integration authorization events emit audit records per the Logging and Audit Policy.

5. Dependency and Vulnerability Management

5.1. Dependency Inventory. Third-party libraries are tracked. New dependencies require review for license compatibility and security posture.

5.2. Vulnerability Scanning. Dependencies are monitored for published vulnerabilities. Critical and high severity issues are prioritized for remediation per the Vulnerability Disclosure Policy.

5.3. Patch Cadence. Security patches are applied on a risk-based schedule. Emergency patches may be deployed outside normal cadence for active exploitation or critical exposure.

6. Testing and Assurance

6.1. Automated Testing. Unit, integration, and regression tests cover authentication, authorization, tenant isolation, and critical business workflows where practicable.

6.2. Security Testing. Static analysis, dynamic testing, and periodic penetration tests complement manual review. Findings are tracked to resolution.

6.3. Support Mode Testing. Tests verify Support Mode and Partner Support Mode require tickets, reasons, MFA where applicable, duration limits, customer notification, and audit emission.

6.4. Operational Evidence Integrity. Tests verify Operational Evidence records maintain timestamps, attributions, and immutability properties appropriate to audit and compliance use cases described in Documentation.

7. Data Handling in Development

7.1. Engineers must not copy production Customer Data to local machines except under approved procedures with encryption and deletion requirements.

7.2. Logs and debug output must exclude passwords, tokens, secrets, and unnecessary Personal Data. Audit replay sanitizes sensitive metadata keys.

7.3. MiseCentral does not use Customer Data to train foundation models for unrelated customers unless authorized in the Agreement.

8. Incident Response Integration

8.1. Security defects discovered during development are reported through internal channels and prioritized per severity.

8.2. Hotfix procedures exist for active exploitation with post-incident review and regression tests.

9. Training

9.1. Engineering personnel receive secure coding training upon hire and periodically thereafter, including hospitality data sensitivity, tenant isolation, and Support Mode governance.

10. Policy Review

10.1. This Policy is reviewed at least annually and upon material architecture changes.

11. Contact

MiseCentral LLC Attn: Security — Secure Development 8 The Green, Suite A Dover, DE 19901 United States security@misecentral.com