Skip to content

Security and Compliance Policy

This document defines a baseline security and compliance posture, including authentication/authorization, secrets handling, data classification, logging/auditing, and minimal expectations for Factory-generated services and platforms. It is written for security teams, compliance officers, architects, and customers evaluating ConnectSoft's security practices.

ConnectSoft maintains a security-first architecture across all products, with encryption, access control, audit logging, and compliance considerations built into every platform. This policy guides architecture decisions, partner enablement, and contract discussions.

Important

Policy & Design Intent: This document describes policy and design intent, not a legal guarantee. Actual security certifications and compliance status are defined in contracts and official certifications. ConnectSoft aims for "compliance-ready by design" but references certifications only when truly achieved.

Security Objectives and Scope

Objectives

  • Protect Customer Data - Ensure customer data and tenant isolation
  • Auditable Systems - Provide auditable systems via Audit Platform
  • Enable Compliance - Enable future compliance certifications (SOC2, GDPR, HIPAA)
  • Security-First Design - Build security into architecture from the start

Scope

This policy applies to: - AI Factory and agent execution - SaaS Platforms (Identity, Audit, Config, Bot) - Factory-generated services - Partner-delivered solutions (baseline expectations)

See: Factory Overview for Factory architecture.

See: Product Portfolio - Platforms for platform details.

Identity, Access, and Authentication

High-Level Rules

  • Standardized Identity - Use standardized identity (Identity Platform, OpenID Connect, OAuth2)
  • Principle of Least Privilege - Grant minimum necessary permissions
  • Multi-Tenant Isolation - Enforce tenant isolation at authentication level
  • Service-to-Service Auth - Support service-to-service authentication (client credentials)

Authentication Standards

Customer-Facing Services: - OAuth2/OIDC via Identity Platform - Token-based authentication - Multi-factor authentication (MFA) support

Service-to-Service: - Client credentials flow - Service principals - Managed identities (Azure)

See: Identity Platform API Overview for authentication details.

See: Security & Compliance for security requirements.

Secrets Management and Configuration

Baseline Expectations

  • No Secrets in Source Code - No secrets in source code or configuration files
  • Secure Secret Storage - Use secure secret storage (e.g., Azure Key Vault conceptually)
  • Runtime Loading - Secrets loaded from secure provider at runtime
  • Factory-Generated Services - Factory-generated services must use options/config with secret providers

Secrets Management Checklist

  • No plain-text secrets in repos
  • Secrets loaded from secure provider at runtime
  • Secret rotation supported
  • Access to secrets logged and audited
  • Secrets encrypted at rest and in transit

Warning

Common Pitfalls: 1. Hardcoding Secrets - Developers hardcoding secrets in code or config files 2. Logging Tokens - Accidentally logging tokens or credentials in logs 3. Commit Secrets - Committing secrets to version control 4. Shared Secrets - Sharing secrets via insecure channels (email, chat)

See: Cloud-Native Mindset for configuration principles.

Logging, Auditing, and Monitoring

Logging Requirements

Minimal Logging Requirements: - Errors and warnings - Key business events - Security-sensitive operations - Structured logging with correlation IDs

Log Format: - Structured logging (JSON) - Correlation IDs for request tracing - Timestamps and log levels - No sensitive data in logs

Auditing Requirements

Use of Audit Platform: - Key security-sensitive actions recorded - Access control changes - Configuration changes - Data access events

Audit Event Types: - Authentication events - Authorization events - Data access events - Configuration changes

See: Audit Platform API Overview for audit details.

See: Observability-Driven Design for observability principles.

Monitoring Requirements

Integration with Observability Stack: - OpenTelemetry for distributed tracing - Metrics collection and alerting - Health checks and status endpoints - Dashboard and alerting setup

See: Monitoring and Dashboards for monitoring details.

Baseline Expectations Table

Area Baseline Expectation
Logging Structured, with correlation IDs
Auditing Key security-sensitive actions recorded
Monitoring Health checks, metrics, alerting thresholds

Data Classification and Handling

Data Classification

Simple Classification:

Classification Description Handling Expectations
Public Publicly available information No special handling required
Internal Internal use only Access control, basic encryption
Confidential Sensitive business information Encryption at rest/in transit, access control, audit logging
Sensitive Highly sensitive (PII, financial) Strong encryption, strict access control, audit logging, masking/redaction

Handling Expectations

Encryption: - At Rest - Encrypt confidential and sensitive data - In Transit - Use TLS/HTTPS for all data in transit - Key Management - Use secure key management (Azure Key Vault)

Access Control: - Role-based access control (RBAC) - Principle of least privilege - Regular access reviews

Masking/Redaction: - Mask sensitive data in logs - Redact PII in audit logs where appropriate - Use data masking in test environments

Note

Detailed classification per-project may evolve later. This provides a baseline framework that can be customized per customer or project requirements.

Compliance Alignment and Roadmap

Design Intent

Compliance-Ready by Design: - Design influenced by practices compatible with frameworks like SOC2, GDPR, HIPAA - Architecture supports compliance requirements - Not claiming actual certification unless specifically stated elsewhere

Future Steps

Short-Term: - Security policies and procedures - Security training for team - Regular security assessments

Medium-Term: - SOC 2 Type II preparation - GDPR compliance documentation - HIPAA readiness assessment (if applicable)

Long-Term: - SOC 2 Type II certification - Industry-specific certifications (as needed) - Continuous compliance monitoring

Decision

Compliance Decision: ConnectSoft aims for "compliance-ready by design" but references certifications only when truly achieved. Design is influenced by practices compatible with frameworks like SOC2, GDPR, HIPAA, but we do not claim actual certification unless specifically stated elsewhere.

Security Requirements for Factory-Generated Services

Minimal Checklist

Any Factory-generated service MUST:

  • Use Central Identity/Auth Pattern - Integrate with Identity Platform or use standard OAuth2/OIDC
  • No Secrets in Code - Use secure config source (Azure Key Vault, environment variables)
  • Basic Role/Permission Checks - Implement role/permission checks for protected operations
  • Logging and Error Handling - Implement structured logging and proper error handling
  • Sensitive Data Redaction - Redact sensitive data in logs where applicable
  • Audit Integration - Emit audit events for critical operations
  • Observability Hooks - Include observability hooks (logging, tracing, metrics)

See: Microservice Template for template security features.

See: Agent Microservice Standard Blueprint for standard blueprint.

See: Observability-Driven Design for observability requirements.

See: Audit Platform API Overview for audit integration.