System Configuration and Processing Guidelines

Version1.0
Effective DateApril 2026
Review CycleAnnual
Document OwnerChief Information Security Officer (CISO)
ClassificationCONFIDENTIAL — Internal Use Only
Applicable StandardSOC 2 Type II

1. Purpose

This document defines the guidelines and controls governing how DCKAP Integrator is configured — both at the platform infrastructure level and at the individual customer integration level — to ensure that system processing meets accuracy, security, and performance requirements.

2. Platform-Level Configuration Standards

2.1  Infrastructure Configuration

ComponentConfiguration StandardOwner
API GatewayTLS 1.2+ enforced; rate limiting enabled; WAF rules activePlatform Engineering
Message QueueDurable queues with at-least-once delivery; DLQ enabledPlatform Engineering
Processing WorkersAutoscaled; CPU/memory limits set; health checks every 30sPlatform Engineering
Database (Config Store)Encrypted at rest (AES-256); daily backups; point-in-time recoveryPlatform Engineering
Credential VaultSecrets encrypted with customer-specific keys; access loggedSecurity Engineering
Logging PipelinePII masking applied before log storage; logs immutable for 90 daysPlatform Engineering

2.2  Security Configuration Baseline

  • No default credentials in use — all service accounts require unique, rotated credentials.
  • Principle of least privilege enforced — each service has only the permissions it needs.
  • All configuration changes logged in the infrastructure change management system.
  • Production configuration changes require peer review and change advisory board (CAB) approval.

3. Customer Integration Configuration Guidelines

3.1  Connector Configuration

  • Each connector must have a dedicated, scoped API credential — shared credentials are not permitted.
  • API credentials are stored in the DCKAP Vault and never exposed in logs or UI after initial entry.
  • Connector endpoint URLs must use HTTPS — HTTP-only endpoints will be rejected by the platform.
  • Credential rotation must be performed at least annually or immediately upon suspected compromise.

3.2  Data Flow Configuration

  • Every integration flow must have at least one mandatory field defined — unmapped flows are blocked from activation.
  • Business rules must be tested in sandbox mode before activation on production data.
  • Customers are recommended to enable ‘strict mode’ which rejects records with any unmapped field.
  • Error notification email must be configured before an integration flow is activated.

3.3  Sync Schedule Configuration

SettingPermissible RangeDefault
Scheduled Sync Interval1 minute to 24 hoursEvery 1 hour
Retry Attempts0 to 53
Retry Back-offExponential, 30s base, max 30 minutesExponential
Dead-letter Retention1 to 30 days7 days
Batch Size1 to 5,000 records per API call100

4. Configuration Change Management

  • All customer configuration changes are timestamped and attributed to the user who made them.
  • Configuration history is retained for 1 year and is available to customer admins in the portal.
  • Rollback to any previous configuration version is available within the configuration history view.
  • Critical configuration changes (credential updates, flow deactivation) trigger email notifications.

5. Placement in Product

Product LocationScreen / PageAudience
Product PortalSettings → Integration ConfigurationCustomer Admins
Product PortalSettings → Configuration HistoryCustomer Admins, Auditors
Trust CenterSecurity → Platform Configuration StandardsAuditors
Internal WikiEngineering → Infrastructure ConfigurationPlatform, Security Teams
Help CenterConnector Setup GuidesAll Users