This section is deliberately written as a required/intended control framework. Change a row to an unconditional claim only after it is implemented, documented, and tested.
1.1Security Objective
Lunark Dynamics LLC intends to maintain administrative, technical, and organizational measures appropriate to the nature of POSTARYX, the sensitivity of OAuth credentials and User Content, platform requirements, and reasonably foreseeable threats. Security is an ongoing program rather than a guarantee of absolute protection.
The production security posture should be documented internally and kept consistent with public representations, platform Data Protection Assessments, customer security questionnaires, and actual system behavior.
Control area
Required / intended practice
Production verification
Encryption in transit
Use current TLS for production website, API, administrative, and service-to-service traffic where technically appropriate.
[VERIFY TLS configuration / certificate management]
Encryption at rest
Use storage/database encryption for production data where supported and appropriate, with additional protection for sensitive credentials.
[VERIFY database/object storage configuration]
OAuth token protection
Encrypt or otherwise strongly protect OAuth access/refresh tokens; separate encryption keys from token storage where feasible.
[VERIFY token encryption and key custody]
Secret management
Store platform app secrets, database credentials, signing secrets, and environment secrets in an access-controlled secret-management mechanism rather than source code.
[VERIFY actual secret manager and rotation process]
Least privilege
Grant production/data access only to named personnel and service identities that need it; avoid shared administrative logins.
[VERIFY IAM roles and access-review cadence]
Authentication security
Use secure password hashing where passwords are managed by POSTARYX; support appropriate session controls and MFA for privileged access.
[VERIFY auth provider / password hashing / admin MFA]
Logging / auditability
Record security-relevant and operational events needed for troubleshooting, abuse prevention, and incident investigation while avoiding raw secrets.
[VERIFY log sources, redaction, access, and retention]
Monitoring and alerting
Monitor availability, publishing failures, error rates, abnormal authentication activity, critical integration health, token expiry/revocation indicators, and security events where feasible.
[VERIFY monitors and alert recipients]
Incident response
Maintain an incident-response process with a named owner, triage, containment, eradication, recovery, evidence handling, and notification assessment.
[VERIFY plan, owner, contact tree, notification timeline]
Backups and recovery
Maintain backups appropriate to recovery needs, define retention, protect backup access, and periodically test restoration.
[VERIFY cadence, retention, restore tests, off-provider copy if used]
Token revocation / deletion
Provide connector disconnect procedures that stop use, revoke upstream where supported, and delete local active credentials.
[VERIFY every connector]
Personnel security
Use onboarding/offboarding steps and promptly remove access when personnel no longer require it.
[VERIFY joiner/mover/leaver process]
Vendor / subprocessor management
Maintain an inventory of vendors, evaluate security/privacy posture proportionate to risk, and use appropriate contractual terms.
[VERIFY vendor register / DPAs]
Data minimization / retention
Collect only needed data and maintain deletion/retention schedules, including platform-specific restrictions.
[VERIFY system TTLs / deletion jobs]
Vulnerability / patch management
Track material software and dependency vulnerabilities and apply updates according to risk.
[VERIFY scanning/patch workflow]
Environment separation
Separate production credentials/data from development and test environments as appropriate; do not use personal platform accounts as shared review fixtures.
[VERIFY environment/credential separation]
1.2Sensitive Token and Secret Handling
OAuth tokens, refresh tokens, platform app secrets, customer API keys, app passwords, bot tokens, database credentials, cryptographic private keys, and signing secrets are high-risk data. Production procedures should:
- avoid including raw secrets in logs, analytics events, error traces, support exports, or client-visible responses;
- restrict secret access to the minimum service identities and personnel necessary;
- rotate or revoke secrets after suspected compromise and according to provider guidance;
- delete user-supplied credentials when the relevant connection is removed;
- use distinct production and non-production credentials where supported; and
- document platform-specific token lifetime, refresh, revocation, and reassessment requirements.
1.3Logging, Monitoring, and Privacy
Operational and security logging should be sufficient to investigate incidents and failed publishing without becoming an unnecessary copy of User Content or credentials. Logs should have defined retention, access control, and redaction. Monitoring vendors must be included in the Subprocessor Disclosure if they receive personal data.
1.4Backup Practices
Production backup practices should define: the systems covered; backup frequency; retention; encryption/access; restore procedure; periodic restore-test cadence; deletion handling; and whether an off-provider backup is used. Public language must match actual configuration.
Backup retention placeholder: [Actual Backup Retention Period]. Restore-test cadence placeholder: [Actual Restore-Test Cadence].
1.5Incident Response
The incident-response program should identify a responsible owner and escalation path and include assessment of confidentiality, integrity, availability, token/credential impact, Connected Platform obligations, customer notice, regulator notice, evidence preservation, and lessons learned.
Notification timing must not be stated as a fixed legal deadline unless required by the laws/contracts actually applicable to the incident. Use [Incident Response Owner] and [Incident Notification Procedure] internally.
1.6Customer Security Responsibilities
Customers are responsible for securing their own user devices, Account credentials, Workspace roles, Connected Platform credentials, client authorizations, and exported data. Security is shared: POSTARYX cannot protect a platform account after the user discloses credentials or grants unauthorized people Workspace access.