Privacy Policy for directva
This Privacy Policy explains how directva collects, uses, stores, and shares personal data in the context of providing software development and related services to businesses. The policy is structured around practical examples and scenarios to help clients understand data handling in real projects — for example, onboarding a retail client, integrating a payment provider, or running analytics for an inventory system. We describe what information you may provide, what we generate automatically during service delivery, how we share data with partners during integrations, and the rights available to data subjects. The approach is case-driven: each section highlights a scenario, followed by the measures taken by directva to manage data consistently and transparently.
Key Definitions and Terms
To make the policy actionable in project scenarios, we define key terms used across examples: what counts as personal data in customer integrations, how we define processing activities in a typical software development lifecycle, and the roles of parties when we act as a data processor or controller during integration projects.
- Personal data refers to any information that relates to an identifiable person, such as names, business contact details, device identifiers, or billing information platform during onboarding or integration tests. In project scenarios, personal data often appears in client contact lists, test user accounts, and logs tied to specific user actions.
- Processing means any operation performed on personal data during development and operation of software: collection, recording, organization, storage, modification, retrieval, consultation, use, disclosure by transmission, alignment, erasure, or destruction. For example, processing occurs when we import a client's CRM contacts for a migration project or when automated logs are generated during a deployment pipeline run.
- User denotes an individual who interacts with software built or maintained by directva on behalf of a business client. Scenarios include an inventory manager using a web dashboard, a cashier using a point-of-sale app, or an administrator configuring integrations with third-party services.
- Service means the software development, integration, support, and maintenance offerings provided by directva. Case examples include custom ERP modules, API gateways for payment providers, and analytics dashboards tailored to a client's operational flows.
- Cookies refer to small data files placed on a user's device when accessing web-based services. In scenario-based examples, cookies may support session persistence for admin dashboards or store user preferences in a client portal during trial and testing phases.
Data We Collect
We collect different categories of data depending on the project scenario. Below are categories commonly encountered in business software projects and examples of how each category appears in practice.
Data You Provide
In onboarding and project operations clients provide data necessary to build and operate solutions. Examples include configuration details, user directories, and sample datasets used in migration and testing scenarios.
- Contact information: names, business email addresses, job titles of client personnel provided for project coordination.
- Business and billing information: company registration numbers, invoicing addresses, and purchase order references used for contracting and billing.
- Project data: CSVs, product catalogs, inventory records, and sample transaction logs supplied for migration or integration testing.
- Credentials and access details: API keys or test accounts provided temporarily for integration and validation steps; these are handled with limited access controls.
- Support communications: messages and feedback submitted through support channels during deployment or maintenance incidents.
- Preferences and configuration choices: settings that determine behavior of custom modules and user interface preferences saved during client acceptance testing.
Data Collected Automatically
Certain data is generated or collected automatically as part of service operation, monitoring, and deployment. We document typical automatic data sources and how they are used in practical scenarios.
- Usage logs: timestamps of actions within applications used for debugging and performance analysis in staging and production environments.
- Technical data: IP addresses and device metadata captured during integration tests to detect configuration issues.
- Analytics: anonymized performance metrics used to optimize features across client deployments without profiling individual users.
- Error reports: stack traces and environment details collected when exceptions occur during testing or rollout.
- Security logs: authentication attempts and access patterns recorded to contribute incidents as part of a documented incident response scenario.
- Deployment metadata: release identifiers and build information linked to change management records for traceability.
Third-Party Data Sources
We may receive data from third-party services as part of integrations. Each integration is assessed with a scenario-driven data map to determine what personal data flows through the service and how it is handled.
- Payment processors: transactional metadata and payer identifiers shared during payment gateway integrations; processed under contractual data processing terms.
- Identity providers: user attributes supplied by single sign-on providers used to provision application access during rollout scenarios.
- Analytics platforms: aggregated metrics supplied by external analytics providers used to benchmark feature performance across projects.
Purposes of Processing
We limit processing to purposes required for delivering agreed services. Each purpose is illustrated with a real-world scenario so clients can map data flows to business outcomes.
- Service delivery: building, testing, and deploying software modules using client-provided data in migration and customization scenarios.
- Integration: configuring and validating third-party services (payments, identity, logistics) using test and live credentials supplied for necessary validation.
- Support and maintenance: diagnosing incidents and applying fixes using logs and support communications tied to a specific support ticket scenario.
- Security and fraud detection: monitoring authentication and access patterns to identify and respond to anomalies during simulated attack exercises and real events.
- Compliance and record-keeping: retaining project records and change logs required for contractual audit scenarios and invoicing reconciliation.
- Performance improvement: analyzing anonymized usage data to optimize resource consumption and feature response times across deployments.
- Testing and quality assurance: using synthetic or anonymized datasets in acceptance testing and pre-production runs.
- Client communications: sending project updates, milestone reports, and relevant service notices to designated contacts.
Legal Bases for Processing
We rely on legal bases appropriate to each scenario. For B2B relationships common bases include performance of a contract, legitimate interests for operational needs, and compliance with legal obligations where required.
- Performance of a contract: processing necessary to provide agreed software development and maintenance services.
- Legitimate interests: limited processing to maintain platform security, troubleshoot incidents, and improve service reliability, balanced by risk assessments.
- Consent: where optional marketing communications or analytics require explicit consent, we seek it separately and document the consent scenario.
- Legal obligation: processing required to meet local regulatory or tax record-keeping duties specified in contractual or statutory scenarios.
Data Subject Rights (GDPR-style)
Although directva operates in Thailand, we recognize common data subject rights and provide mechanisms inspired by GDPR principles. In practice we apply these rights to requests received in project scenarios and document actions taken to fulfill valid requests.
- Right to access: clients and users may request confirmation of whether we process their personal data and request a copy of that data used in a given project scenario.
- Right to rectification: where data used in integrations or migrations is inaccurate, we support correction workflows as part of the migration case and update records accordingly.
- Right to erasure: subject to contractual and legal retention needs, we can remove personal data from active environments in the context of a decommissioning or offboarding scenario.
- Right to restriction: in specific cases we can limit processing while a data accuracy dispute or compliance review is ongoing, following documented change control steps.
- Right to data portability: where feasible, we can export structured data provided during a project to facilitate client migrations to another provider.
- Right to object: clients can object to certain processing for direct marketing or analytics outside core service delivery; we document the objection and take appropriate steps.
Cookies and Similar Technologies
We use cookies only as necessary for service operation and client portals. Each use is explained with practical examples, such as session cookies for dashboard access during acceptance testing.
Types used include session cookies for authentication persistence, performance cookies for load testing, and functional cookies to remember interface settings during configuration sessions.
Categories include essential cookies required for service function, analytics cookies used in aggregated performance testing, and optional cookies that require explicit consent when used for non-essential analytics.
Clients and users can manage cookie preferences via application settings or browser controls. For client portals we include an options panel to toggle non-essential analytics during pilot and production phases.
Cookie Policy
Data Sharing and Recipients
Data is shared only when necessary to deliver services or when required by law. Each sharing case is assessed and documented in integration plans and subcontractor agreements.
- Service providers: cloud hosts, CI/CD providers, and monitoring services engaged under contractual terms and limited to necessary processing in a deployment scenario.
- Third-party integrations: payment gateways, identity providers, and logistics APIs when clients authorize integrations as part of a project.
- Professional advisors: legal and accounting advisors when required to address compliance or billing matters related to a project.
- Acquirers and successors: in the event of a business transfer, data may be shared with potential buyers or their advisors under confidentiality and data-handling obligations.
- Legal authorities: disclosures made when required by law, court order, or to comply with regulatory contribute relevant to a given scenario.
- Aggregated reporting recipients: anonymized and aggregated project metrics shared for benchmarking and service improvement without identifying individuals.
International Data Transfers
Some integrations and cloud services involve cross-border data transfers. Each transfer is documented in project data flow maps and handled under appropriate safeguards aligned with contractual commitments and applicable law.
Safeguards include data processing agreements, standard contractual clauses where appropriate, encryption in transit and at rest, and minimizing personal data retained in cross-border systems through pseudonymization in testing scenarios.
Data Retention
Retention periods depend on the type of data and the scenario. We retain only what is necessary for the operational, contractual, or legal purpose and document retention schedules per project.
Account and contact records: retained for the duration of the client relationship plus a defined archival period for billing and historical reference tied to the contractual scenario.
Support and project communications: retained for the life of the project and archived for a limited period to support post-implementation maintenance and dispute resolution.
Operational logs: retained according to security and troubleshooting needs; high-detail logs are retained for a shortened period while aggregated logs used for analytics may be kept longer in anonymized form.
When data is no longer needed for the purpose collected and no legal obligation requires retention, we securely delete or anonymize records following documented decommissioning procedures used in past offboarding cases.
Security Measures
Security measures are implemented according to practical risk assessments conducted for each project scenario. We apply layered controls that reflect the sensitivity of data involved and the operational context of each integration or deployment.
- Access controls and least-privilege practices in development, staging, and production environments, enforced via role-based access scenarios and periodic reviews.
- Encryption of data in transit and at rest for all production environments and for sensitive test datasets used during migrations.
- Regular backups, secure key management, and incident response playbooks derived from real incident scenarios and tabletop exercises.
Your Rights and How to Exercise Them
We provide mechanisms to exercise rights described in this policy. Requests are handled in line with documented workflows and validated to ensure proper identity verification, while respecting contractual obligations and legal constraints.
- Access request: submit a request to confirm whether personal data is processed and to receive a copy of relevant records tied to a project scenario.
- Correction request: provide details and evidence for data that should be rectified in migration or live systems; corrections are tracked through change requests.
- Deletion request: request removal of personal data from active systems; deletion requests are evaluated against retention needs and contractual record-keeping.
- Portability request: request export of your structured data for migration; exports follow secure transfer procedures used in client handover scenarios.
- Objection or restriction: raise objections to processing outside core service obligations; we will review and apply appropriate technical and operational restrictions where feasible.
- Right to withdraw consent for processing personal data where processing is based on consent, described using a real-case example: a pilot marketing campaign where a user withdrew consent and data flows were stopped within operational limits.
- Right to lodge a complaint with a supervisory authority in Thailand if a user believes processing does not comply with applicable law; we include a scenario describing steps taken internally before external referral.
- Right to restrict or object to certain processing activities, illustrated by a case where a corporate client limited profiling used for analytics while retaining service delivery.
How to exercise your privacy rights
Requests to access, correct, delete, restrict, port, or object to processing of personal data can be submitted via the contact form on directva.club or by mail to our office. We recommend including a clear description of the request, a copy of an ID for verification, and any relevant examples or case references to speed up handling. For corporate representatives, include business ID 0399825763156 and an authorization letter when applicable. In practice, we handle requests with structured intake and verification steps to protect privacy while acting on legitimate requests.
[email protected]
We aim to respond to valid requests within 30 calendar days of receipt. Complex requests or those requiring verification may take longer; in such cases we will notify you with an estimated timeline and reference any applicable legal bases for the extension.
Marketing communications and case-driven updates
directva sends marketing that focuses on practical case studies, product updates, and scenario-based guidance for business software development. Examples include monthly case summaries of implementation patterns for SMEs in Thailand and invitations to webinars demonstrating workflow improvements. Communications will be tailored to interests you specify and may include aggregated case examples that do not reveal personal data. You can manage preferences any time through your account settings or the unsubscribe options included in each message.
To opt out of marketing, use the unsubscribe link in any communication from directva, update preferences on your account at directva.club, or contact our office at +66965744983. Unsubscribe requests are processed promptly; we may continue to send non-marketing service-related notices such as contractual updates.
Children and personal data
directva is designed for business use and does not target children. We do not knowingly collect personal data from individuals under 16 without verified parental or guardian consent. If we learn that we have collected data about a child without appropriate authorization, we follow a documented removal and notification scenario based on the nature of the data and applicable law.
Third-party links and integrations
Our site and services may link to or integrate with third-party platforms and tools as part of business use cases (e.g., payment processors, analytics, cloud hosting). These external services have their own privacy practices. Practical onboarding examples and integration checklists are provided to clients so they understand data flows and control points before enabling connectors.
Policy updates and revision history
We update this Privacy Policy to reflect operational changes, new case studies, or regulatory developments. The policy effective date is 21-03-2026. When changes are material, we publish a summary of what changed and provide context with examples of how those changes affect users and business scenarios.