Alavna Information Security Policy

Tertibo application and supporting services

Version 1.0 | Published 18 September 2026 | Owner Alavna LLC management
Security contact info@tertibo.com | Review due 18 September 2027

Purpose and scope

Alavna LLC operates Tertibo. This policy defines the security requirements for protecting customer information and the systems that process it. It applies to personnel, contractors, administrator accounts, development devices, application code, cloud services, vendors, and Tertibo's mobile and web applications.

The policy covers account information, user-created content and attachments, financial information, authentication material, and operational records. Its requirements guide implementation, risk reviews, and corrective work. The privacy notice at https://tertibo.com/privacy describes customer data handling and choices. This security policy does not grant permission to collect additional data or change those choices.

Security responsibility

Alavna management is accountable for information security and must designate an individual to maintain this policy, review access and risks, coordinate incidents, and track corrective work. In a small organization, the company owner may perform this role. The internal responsibility record must name the individual, actual title, primary contact, and backup or recovery arrangement.

Security concerns may be reported to info@tertibo.com. Reports should describe the concern and affected feature without including passwords, bank credentials, access tokens, or unnecessary personal information. The designated owner must review the contact inbox each business day and respond to urgent reports promptly when received.

People with access to company systems must understand the requirements relevant to their work before receiving access and acknowledge them annually. They must report suspected compromise, lost devices, accidental disclosure, and unsafe access promptly.

Risk management

The security owner must maintain an inventory of systems, sensitive data, administrators, service identities, and critical vendors. Review risks at least quarterly and before material changes to authentication, financial-data handling, external processing, or storage.

For each risk, record the affected asset, threat, current controls, likelihood, impact, action owner, deadline, and resolution evidence. Prioritize actual exposure of sensitive data, compromised credentials, and unauthorized access. Risks must have a documented treatment rather than being silently accepted.

A temporary exception requires a reason, compensating controls, residual risk, accountable approver, and expiry no later than 90 days. Reassess it at expiry. Exceptions cannot override applicable obligations or justify an inaccurate statement to customers or a service provider. An unresolved risk of unauthorized financial-data access must block the affected real-data feature.

Data handling

Treat customer content, attachments, financial records, credentials, and access tokens as restricted information. Nonpublic source code and operational records are internal information. Public information must be deliberately approved for publication.

Collect and process only information necessary for the disclosed feature and authorized purpose. Limit access and exports to that purpose. Restricted information must not appear in public repositories, public screenshots, unrestricted analytics, or ordinary support messages. Use synthetic or appropriately deidentified information for tests and demonstrations. Separate test credentials and environments from production.

Access and device security

Use individually attributable administrator accounts and grant the minimum permissions required. Multifactor authentication is required for business email, cloud administration, source hosting, Plaid Dashboard, and other administrative services that can expose customer information or secrets. Store unique credentials in an approved password manager and protect recovery material separately.

Record access grants, their purpose, permissions, and approver. Review access quarterly and after role changes. Revoke access promptly when no longer needed, including on departure, and rotate shared secrets the departing person could access. Document and review emergency access.

Customer requests must authenticate the caller and enforce ownership at the server or data-service rules. Never trust a caller-supplied user identifier as proof of ownership. Privileged server processes must validate their target and input because they may bypass client-facing database rules.

Devices used for administration or development must use full-disk encryption, automatic locking within five minutes, supported operating systems, current security updates, and available malware protections. Secure devices physically. Report loss immediately and remove company access and data before reassignment or disposal.

Encryption and secrets

Use HTTPS with TLS 1.2 or later and certificate validation for restricted information in transit. Require encryption at rest for managed databases, object storage, backups, and devices that hold restricted information. Verify provider and device settings before asserting coverage.

Store production secrets in a managed secret service with restricted access. Keep provider access tokens on the server, encrypt them using authenticated encryption, and protect the encryption keys separately. Never place secrets in application bundles, source control, AI prompts, or logs.

Maintain key ownership and rotation procedures. Revoke or rotate credentials promptly after suspected compromise or unauthorized disclosure. Verify that rotation preserves authorized access to retained data and that old credentials no longer work.

Development and vulnerability management

Record production changes in version control with their purpose, security impact, verification, approval, and rollback plan. Review changes to authorization, sensitive data, secrets, deletion, and external processing before release. A sole maintainer must document self-review and seek independent review for high-risk changes where feasible; self-review must not be described as independent review.

Run relevant automated tests and dependency checks, and review for accidentally included secrets before release. Test cross-user access denial, unauthenticated requests, malformed inputs, webhook verification, and deletion failure handling when those paths change. Do not weaken tests to make a release pass.

Review vulnerability advisories weekly and scan dependencies at least monthly and before release. Triage findings by severity, exposure, and exploitability. Internal remediation targets after validation are: active exploitation or critical exposure, immediate containment and a fix within 72 hours; high severity, 14 days; medium, 30 days; low, 90 days. If a target cannot be met, isolate the affected capability or document a time-limited exception. Record verification of each fix.

Monitoring and operational records

Record appropriate security events, including administrative access, permission changes, deployments, rejected authentication and webhooks, and security-relevant failures. Minimize identifiers and exclude credentials, bank tokens, complete financial payloads, customer messages, and attachments. Restrict log access and protect records from unauthorized alteration.

Configure actionable alerts to reach the security owner and verify delivery. Review alerts each business day and act promptly on urgent alerts when received. Review recurring failures and unresolved findings monthly. This procedure does not imply continuously staffed monitoring.

Maintain a retention register for each log source. The standard target for routine operational security logs is 30 days; a longer period requires a documented purpose or applicable obligation. Keep minimized security review and incident records for 12 months unless a justified requirement calls for a different period. Verify actual service settings and record deviations.

Vendors and AI processing

Maintain a register of the providers actually used, their purpose, information received, permissions, retention, security terms, incident contacts, and deletion support. Review critical providers annually and before changing how restricted information is shared. A vendor's certification does not certify Alavna or its configuration.

Never send credentials, private keys, or bank access tokens to an AI model. Send customer information only when necessary for the requested feature and permitted by the applicable notice, permissions, and approved provider terms. Assess each enabled provider and fallback route, including its retention and model-training terms. Minimize personal information included in external searches.

Financial connections

Use the provider's supported linking flow for bank authentication; Alavna must not collect or store bank login credentials. Limit requested products and information to the authorized purpose. Keep provider access tokens and raw Item identifiers in restricted server storage bound to the correct user, and expose only the minimum safe application identifiers to clients.

Verify webhook signatures, timestamps, body integrity, and environment before acting. Reject invalid or malformed events and make processing safe to retry. Sandbox support does not establish production readiness; real-data use requires verification of production configuration, ownership controls, disclosures, and provider authorization.

Provide a way to disconnect a bank and stop further collection. Revoke the provider connection when no longer required. Distinguish disconnection from deletion of previously imported history. Account deletion must address provider revocation, application records, attachments, auxiliary owner mappings, and failures requiring a retry.

Retention and deletion

Maintain a register of data categories, purposes, locations, retention periods or triggers, deletion methods, backup treatment, and responsible owners. Align it with the privacy notice. Verify a requester's identity before disclosing or deleting account information; an unverified email sender address alone is insufficient.

For deletion, identify applicable stores and vendors, revoke connected access where appropriate, remove account-owned information, verify the result, and track failures to resolution. Preserve the credentials needed to retry provider revocation until it succeeds. Retain only minimal evidence of completion. Any required retention or technical delay must be documented and explained accurately. Do not promise immediate erasure from backups or provider logs unless it is supported by the actual design and terms.

Recovery and service continuity

Document recovery procedures for critical services, loss of an administrator account or device, and loss of access to secrets. Set recovery time and recovery point objectives based on the business and customer impact. Do not publish recovery guarantees without evidence that they can be met.

Before relying on recoverability of real financial records, establish an encrypted backup or equivalent recovery design with documented frequency, retention, access restrictions, and cost approval. Managed hosting availability alone is not evidence that deleted or corrupted records can be restored.

Test recovery at least annually and after material changes in an isolated environment. Verify data integrity, ownership controls, measured recovery time, and potential data loss. Reapply deletion records before restoring service so recovery does not silently recreate deleted customer information. Securely remove temporary test copies.

Incident response

The security owner coordinates incident response and maintains contacts for leadership, affected vendors, and qualified legal or forensic support when needed. Anyone discovering an incident must report it promptly and preserve relevant evidence.

1. Record and assess the discovery time, affected systems, observed facts, possible exposure, severity, and response owner. Treat suspected credential theft, cross-user access, and financial-data exposure as urgent.
2. Contain the issue by revoking compromised access, isolating affected systems, or pausing the affected integration. Preserve relevant evidence with restricted access.
3. Investigate the timeline, cause, affected users and information, and whether unauthorized access or disclosure occurred. Separate confirmed facts from hypotheses and obtain specialist help when needed.
4. Assess applicable contractual, provider, and legal notification duties promptly. Record the controlling deadlines and notify affected parties within them, using qualified advice where necessary. Do not wait for a complete investigation if a notice is already required.
5. Remediate the cause, rotate affected credentials, verify authorization and integrity, and restore service from a trusted state. Record the decision to resume service and monitor for recurrence.
6. Within ten business days after stabilization, review the incident and assign corrective actions with owners and deadlines. Verify closure.

Run an incident-response exercise at least annually. Record the scenario, participants, outcome, gaps, and follow-up work. An initial walkthrough must confirm who responds and how to reach them.

Review and assurance

Review this policy at least annually and after a material incident or change. Keep dated records of access reviews, risk assessments, vulnerability triage, incident exercises, vendor reviews, and recovery tests. Each record must identify the reviewer, scope, result, evidence, and follow-up work.

External security answers must describe actual operating practices and their evidence. Publishing this policy does not establish that every control has been independently verified. Track incomplete controls internally, and disclose material limitations when answering due diligence questions. No SOC 2, ISO 27001, penetration-test, or other certification is asserted by this policy.

Version history: Version 1.0, 18 September 2026. Replaces the initial draft with reviewed requirements and a separate internal implementation record. Canonical publication: https://tertibo.com/security