Ackaia Corporation Information Security Policy#

Ackaia Corporation v1.00.00 July 24, 2026 1233 York Avenue, Apt. 301 New York, NY 10065 United States of America www.ackaia.com

Effective Date: July 24, 2026

Publisher: Ackaia Corporation, 1233 York Avenue, Apt. 301, New York, NY 10065, United States

(“Ackaia”, “Ackaia Corp.”, “we”, “our”, “us”)

Applies To: Ackaia-operated products, websites, APIs, cloud environments, corporate systems, development environments, information assets, and supporting personnel and providers, unless a more specific security policy applies.

Document Owner: Ackaia Corp. Security

Primary Security Contact: security@ackaia.com

---

Revision History#

Version	Changes	Date
1.00.00	Initial Publication	07/24/2026

---

1. Purpose#

This Information Security Policy establishes Ackaia’s public, company-wide principles for protecting information, systems, products, users, and operations.

Its objectives are to:

protect confidentiality, integrity, availability, authenticity, and resilience;

manage security risk proportionately and continuously;

embed security and privacy into product and system design;

limit access according to business need and verified authorization;

detect, respond to, and learn from security events;

communicate important security boundaries transparently;

support applicable legal, contractual, and regulatory obligations.

This is a public policy. It intentionally does not disclose sensitive configurations, detection logic, network architecture, credentials, incident playbooks, recovery values, or other information that could weaken security.

2. Scope#

This Policy applies to:

Ackaia customer-facing Services;

Ackaia ID and shared identity systems;

CipherDrive™ and other Ackaia applications;

APIs, service-to-service integrations, authorization systems, and messaging infrastructure;

production, staging, development, test, and recovery environments;

source code, repositories, build systems, and deployment pipelines;

corporate devices, accounts, communications, and administrative systems;

information created, received, stored, transmitted, or controlled by Ackaia;

employees, officers, contractors, and other personnel with authorized access;

Service Providers that process Ackaia information or support material systems.

Product-specific security whitepapers and policies supplement this document. Where a specific document establishes a stronger or more precise control for a product, the specific document controls for that subject.

3. Nature of This Policy#

This Policy describes Ackaia’s security program at a high level. It is not:

a guarantee that incidents will never occur;

a representation that every control applies identically to every system;

a certification under ISO, SOC, PCI DSS, HIPAA, FedRAMP, or another framework;

a disclosure of confidential internal procedures;

a substitute for a customer’s own security and compliance assessment;

a contractual service-level commitment unless expressly incorporated into a signed agreement.

A reference to an industry framework means Ackaia uses it as guidance where appropriate; it does not imply certification or complete implementation of every control.

4. Security Principles#

Ackaia’s security program is guided by:

Security by design. Security is considered during architecture, development, review, deployment, and operation.

Privacy by design. Systems should minimize unnecessary collection, access, exposure, and retention.

Zero trust. Access is not trusted solely because of network location, prior access, or organizational role.

Least privilege. People and systems receive only the access reasonably required for their current function.

Defense in depth. Multiple preventative, detective, and responsive controls reduce reliance on a single safeguard.

Secure defaults. Security-relevant features should default to protective configurations where practical.

Separation of duties. Sensitive operations should avoid unnecessary concentration of authority.

Risk proportionality. Controls reflect data sensitivity, threat, exposure, business impact, and technical feasibility.

Resilience. Systems should be prepared to contain failures and recover safely.

Transparency. Material security capabilities and limitations should be described without exposing sensitive defenses.

5. Governance and Accountability#

Ackaia assigns ownership for information-security risk, policies, systems, assets, and incidents.

Security governance may include:

executive oversight of material security risks;

designated owners for Services and information assets;

documented security policies, standards, and procedures;

review of material exceptions and residual risks;

security requirements in product and infrastructure planning;

metrics, reviews, and corrective actions;

coordination among engineering, security, privacy, legal, trust and safety, and operations.

Personnel with security responsibilities are expected to act within defined authority and to escalate material risks.

6. Risk Management#

Ackaia evaluates security risk based on factors that may include:

information sensitivity;

system criticality and exposure;

likelihood and potential impact;

known threats and vulnerabilities;

legal and contractual requirements;

dependency and supply-chain risk;

user and business impact;

recoverability and detection capability.

Risk treatment may include mitigation, avoidance, transfer, acceptance, monitoring, or discontinuation. Material residual risk should be documented and accepted by an authorized owner.

Security assessments may occur during design, before material changes, after significant incidents, during provider review, and periodically based on risk.

7. Asset Management#

Ackaia seeks to identify and manage material information assets, systems, repositories, services, credentials, devices, and dependencies.

Controls may include:

asset ownership;

environment and service inventories;

approved software and dependency records;

classification and handling requirements;

lifecycle status and decommissioning;

identification of critical or externally exposed systems.

Unmanaged or obsolete assets should be removed, isolated, remediated, or formally accepted as risk.

8. Information Classification and Handling#

Ackaia classifies information according to sensitivity, legal obligations, business impact, and intended audience. Internal standards may use categories such as:

Public;

Internal;

Confidential;

Restricted or highly sensitive.

Handling requirements may address:

authorized access;

encryption;

transmission and sharing;

storage location;

logging and monitoring;

retention and deletion;

approved devices and systems;

incident escalation.

Public classification does not waive intellectual-property rights or authorize alteration, impersonation, or misuse.

9. Identity, Authentication, and Access Control#

Ackaia uses identity and access controls designed to ensure that access is attributable, authorized, limited, and reviewable.

Controls may include:

unique user and service identities;

multifactor authentication for sensitive access;

role, attribute, policy, or context-based authorization;

least privilege and need-to-know restrictions;

separation of administrative and ordinary access;

session controls and credential rotation;

access approval, review, and revocation;

rapid revocation for departures, compromise, or role changes;

controls for privileged, emergency, and machine access;

logging of sensitive authorization and administrative events.

Access from a trusted network is not, by itself, sufficient authorization.

10. Zero-Trust Architecture#

Ackaia’s zero-trust direction assumes that no user, device, workload, network segment, or request should receive implicit trust.

Zero-trust controls may evaluate:

authenticated subject identity;

requested resource and action;

device, session, network, or risk context;

assigned roles, policies, and entitlements;

service identity and workload authorization;

current account and security state.

Authorization should be explicit, scoped, time-appropriate, and enforced as close as practical to the protected resource. Security decisions and administrative changes should generate auditable records where appropriate.

11. Credentials, Secrets, and Cryptographic Material#

Passwords, private keys, tokens, API credentials, encryption keys, signing keys, and recovery material must be protected according to sensitivity.

Ackaia’s controls may include:

approved secret-management systems;

prohibition on committing secrets to public source repositories;

restricted access and auditability;

rotation, expiration, and revocation;

separation of environments and purposes;

secure generation using appropriate randomness;

incident procedures for suspected exposure;

minimizing long-lived credentials;

workload identity or short-lived credentials where practical.

Personnel must not share credentials or use production secrets in unapproved environments.

12. Encryption and Key Management#

Ackaia uses encryption where appropriate to protect information in transit and at rest. The selected controls depend on sensitivity, architecture, threat model, and Service requirements.

Key-management controls may address:

generation and randomness;

storage and access;

purpose and environment separation;

rotation and revocation;

backup or recovery where appropriate;

destruction at end of life;

monitoring and response to suspected compromise.

Some Ackaia products use user-controlled or client-side cryptographic material. In a documented zero-knowledge design, Ackaia may intentionally not possess the keys required to decrypt supported user content. Product security documentation controls the exact cryptographic claims, algorithms, key custody, limitations, and recovery behavior.

Ackaia does not describe a Service as end-to-end encrypted or zero-knowledge unless the relevant scope and limitations are documented.

13. Infrastructure and Network Security#

Ackaia uses layered controls intended to protect cloud, network, host, container, application, and storage environments.

Controls may include:

environment and account separation;

network segmentation and restricted administrative paths;

managed firewall, filtering, and rate controls;

hardened configurations and reduced exposed services;

secure remote administration;

encryption of network traffic;

monitoring of security-relevant events;

protection against common network and application attacks;

capacity, availability, and abuse controls;

timely removal of unused systems and access.

Infrastructure changes should follow authorized configuration and change-management processes.

14. Secure Software Development Lifecycle#

Security is integrated into Ackaia’s software-development lifecycle according to system risk.

Practices may include:

security requirements and threat modeling;

architecture and design review;

peer review and protected branches;

automated testing and static analysis;

dependency, package, and secret scanning;

input validation and output handling;

authentication and authorization testing;

environment separation;

controlled deployment and rollback;

security review for material changes;

post-deployment monitoring;

remediation and lessons learned.

Development, test, and sample data should avoid real personal information where feasible. Production information must not be copied into lower environments without authorization and appropriate safeguards.

15. Application and API Security#

Ackaia applications and APIs should implement controls appropriate to their exposure and function, which may include:

authenticated and authorized access;

server-side enforcement of permissions;

validation of inputs and requests;

protection against injection, cross-site scripting, request forgery, insecure object references, and related risks;

rate limiting and abuse prevention;

secure session, cookie, and token handling;

replay protection where required by the threat model;

scoped service-to-service credentials;

versioning and deprecation procedures;

logging without unnecessary exposure of secrets or sensitive payloads;

safe error handling.

Security controls implemented in a user interface must also be enforced by the authoritative backend or service boundary where applicable.

16. Logging, Monitoring, and Detection#

Ackaia collects security and operational events necessary to detect threats, investigate incidents, enforce policy, and maintain reliability.

Logging may cover:

authentication and recovery;

authorization and policy decisions;

administrative changes;

credential and token lifecycle;

significant configuration and deployment events;

security alerts and suspicious activity;

application, API, and infrastructure errors;

rate, quota, and abuse events;

relevant data-access or sharing actions.

Logs should be protected from unauthorized access and alteration, retained according to risk and law, and designed to avoid unnecessary secrets or content. Detection methods and thresholds are confidential and may change in response to threats.

17. Vulnerability Management#

Ackaia maintains processes to identify, assess, prioritize, remediate, mitigate, and verify vulnerabilities.

Sources may include:

dependency and package advisories;

automated scanning;

code and architecture review;

penetration testing or focused security testing;

provider notices;

responsible reports from researchers;

incident findings;

threat intelligence.

Remediation priority may consider exploitability, exposure, data sensitivity, user impact, privilege required, active exploitation, available mitigation, and operational risk.

Where immediate remediation is not feasible, Ackaia may apply compensating controls, restrict exposure, monitor the risk, or disable an affected feature.

18. Patch and Configuration Management#

Systems and dependencies should receive security updates according to risk, compatibility, and operational requirements.

Ackaia seeks to:

track material vulnerabilities and updates;

prioritize actively exploited and high-impact issues;

test changes proportionately;

use maintained software versions where practical;

document and monitor deferred remediation;

remove unsupported components or isolate them with compensating controls;

maintain secure configuration baselines for critical systems.

19. Security Testing and Responsible Disclosure#

Ackaia may perform automated and manual security testing, architecture review, threat modeling, code review, penetration testing, and recovery exercises according to risk.

External researchers must follow the Ackaia Corporation Responsible Disclosure Policy. Good-faith research within that policy is welcomed.

Research must not:

access or expose another person’s data;

disrupt the Services;

use illegal material or live malware;

perform social engineering;

publicly disclose an unresolved vulnerability in a way that increases risk;

bypass safety systems for abusive purposes.

20. Third-Party and Supply-Chain Security#

Ackaia evaluates material Service Providers and dependencies according to the access, information, and operational risk involved.

Controls may include:

security and privacy due diligence;

contractual confidentiality, security, and incident obligations;

least-privilege integration and scoped access;

review of data location and subprocessors where relevant;

dependency integrity and update monitoring;

credential separation and rotation;

contingency planning for critical providers;

reassessment after material changes or incidents;

termination and data-return or deletion procedures.

Use of a provider does not transfer Ackaia’s responsibility to manage the risks within its control.

21. Personnel Security#

Personnel with access to Ackaia systems or information are subject to safeguards appropriate to their role.

These may include:

confidentiality and acceptable-use obligations;

identity and eligibility checks where lawful and appropriate;

security and privacy awareness;

role-specific training;

access approval and least privilege;

prompt access changes when responsibilities change;

disciplinary or contractual consequences for misuse;

offboarding and return or deletion of Ackaia information.

Personnel must report suspected incidents, credential exposure, policy violations, and material security weaknesses promptly.

22. Endpoint and Remote-Work Security#

Devices used to access sensitive Ackaia systems should be appropriately protected.

Controls may include:

supported operating systems and security updates;

device encryption;

screen locking and strong authentication;

malware protection and host monitoring;

restricted administrative privileges;

secure remote access;

separation of personal and corporate information where appropriate;

remote revocation or wipe capability for managed devices;

restrictions on untrusted extensions, software, and removable media.

Personnel are responsible for physical protection of devices and must promptly report loss, theft, or suspected compromise.

23. Physical and Environmental Security#

Ackaia uses cloud and Service Provider infrastructure as well as corporate work environments. Physical controls are applied according to the environment and Ackaia’s level of control.

Controls may include:

restricted access to offices, devices, and sensitive records;

visitor and equipment procedures;

secure disposal;

provider assurance for datacenter physical and environmental controls;

protection against theft, damage, and unauthorized observation.

Ackaia does not claim direct control over a provider’s facilities beyond contractual rights and available assurance.

24. Data Minimization, Retention, and Disposal#

Ackaia seeks to collect and retain only information reasonably necessary for defined product, security, legal, and operational purposes.

Retention and disposal controls may include:

documented retention criteria;

deletion or anonymization when information is no longer required;

lifecycle rules for logs, backups, temporary data, and abandoned objects;

legal holds and security preservation;

secure deletion or cryptographic erasure where appropriate;

deletion requirements for Service Providers;

controls for decommissioned media, systems, and Accounts.

Backup or immutable records may be removed on a delayed lifecycle where immediate deletion is not technically feasible.

25. Backup, Continuity, and Disaster Recovery#

Ackaia maintains resilience measures proportionate to Service criticality and architecture.

Measures may include:

backups or replication;

geographic or failure-domain separation;

restoration and recovery procedures;

service dependency mapping;

alternate communication and operational processes;

capacity and availability planning;

recovery testing;

defined recovery priorities.

No backup architecture guarantees that all information can always be recovered. Product Terms may require users to maintain independent copies, especially where user-controlled encryption keys are necessary for recovery.

26. Incident Response#

Ackaia maintains an incident-response process designed to:

receive and validate reports;

triage and classify events;

contain affected systems or access;

preserve relevant evidence;

investigate scope and root cause;

eradicate threats and remediate weaknesses;

recover services safely;

notify affected parties where required;

document lessons and corrective actions.

Response may involve security, engineering, privacy, legal, trust and safety, communications, leadership, Service Providers, and competent authorities.

Incident details may remain confidential while investigation or remediation is active or where disclosure would increase risk.

27. Security and Privacy Incident Notification#

Ackaia evaluates notification obligations based on affected information, jurisdiction, risk, contractual commitments, and applicable law.

Where required, Ackaia will notify affected users, organizational customers, regulators, authorities, or other parties within the legally or contractually applicable period.

Notices may describe:

the nature of the incident;

affected information or systems;

actions Ackaia has taken;

recommended protective steps;

available support or contact information.

Notification may be delayed where legally authorized, necessary to protect an investigation, or required by a competent authority.

28. Change Management#

Material changes to production systems, security controls, infrastructure, and sensitive configurations should be authorized, tested proportionately, traceable, and recoverable.

Change controls may include:

peer review;

automated testing;

deployment approvals;

environment separation;

configuration validation;

rollback or remediation plans;

monitoring after deployment;

emergency-change procedures and retrospective review.

29. Security Exceptions#

An exception to an internal security requirement must be:

based on a documented business or technical need;

evaluated for risk;

approved by an authorized owner;

time-limited where practical;

supported by compensating controls where appropriate;

reviewed or closed when conditions change.

Exceptions do not waive legal or contractual obligations unless authorized by the party entitled to enforce them.

30. Customer and User Responsibilities#

Security is shared. Users and customers are responsible for:

protecting credentials, recovery information, keys, sessions, and devices;

enabling and correctly configuring available security features;

granting access only to authorized people and systems;

promptly revoking unnecessary access;

maintaining current devices, browsers, and integrations;

securing local downloads and exported information;

reviewing public links and integration permissions;

maintaining independent backups where appropriate;

reporting suspected compromise promptly;

complying with applicable Product Terms and law.

Ackaia cannot protect information after an authorized recipient downloads, copies, or redistributes it outside Ackaia’s control.

31. Product-Specific Security Boundaries#

Security capabilities differ among Services. Ackaia documents significant product boundaries separately.

For CipherDrive™, the Security & Encryption Whitepaper describes client-side encryption, zero-knowledge storage, metadata, local-device risk, sharing, key custody, and safety-system boundaries.

Statements about one product do not automatically apply to another product. Customers should evaluate the documentation for each Service they use.

32. Legal Requests, Government Access, and Backdoors#

Ackaia handles legal requests under the Ackaia Corporation Legal Request Response Policy.

Ackaia does not create or maintain a general-purpose backdoor for CipherDrive™. Ackaia cannot disclose plaintext, user-controlled keys, or cryptographic material it does not possess.

Nothing in this Policy prevents Ackaia from complying with valid legal obligations involving information within its possession or control, challenging improper requests, or taking urgent action to protect users and victims.

33. Reference Frameworks#

Ackaia’s security program may draw from recognized practices, including:

NIST Cybersecurity Framework 2.0;

NIST Incident Response Recommendations and Considerations;

CISA Secure by Design;

common secure-development, cloud-security, privacy, and cryptographic practices appropriate to Ackaia’s architecture.

These references provide guidance. They do not represent certification, attestation, or complete adoption of every control.

34. Compliance, Review, and Improvement#

Ackaia may assess compliance through:

technical monitoring;

access and configuration review;

vulnerability and dependency review;

incident and recovery exercises;

internal or external assessment;

policy acknowledgment and training;

corrective-action tracking.

This Policy is reviewed periodically and when material changes occur in law, threats, products, architecture, or operations.

35. Enforcement#

Violations of this Policy may result in:

removal or restriction of access;

credential revocation;

corrective or disciplinary action;

contractual remedies;

termination of employment, engagement, or service access;

legal action or referral to authorities where appropriate.

Enforcement is based on severity, intent, impact, repetition, legal obligations, and other relevant circumstances.

36. Changes to This Policy#

Ackaia may update this Policy to reflect changes in threats, technology, law, Services, architecture, organizational responsibilities, or security practices.

The revision history and effective date identify the current version. Material changes may be announced through the Legal Repository, Ackaia websites, product notices, security communications, or another appropriate channel.

37. Contact#

Report suspected security vulnerabilities according to the Responsible Disclosure Policy.

Security: security@ackaia.com

Privacy: privacy@ackaia.com

Legal: legal@ackaia.com

Abuse: abuse@ackaia.com

Website: www.ackaia.com

Address: 1233 York Avenue, Apt. 301, New York, NY 10065, United States of America

Do not send passwords, access tokens, private keys, recovery phrases, live malware, child sexual abuse material, or unrelated personal information through ordinary email.

---

End of Information Security Policy