You are the controller.
We are the processor.

This page summarises the data processing agreement between Denways Technologies LLP (LLPIN ACY-3781), registered office Varkala, Thiruvananthapuram, Kerala 695310, India, and a customer that uses DenwaysHR to manage its workforce. It is written to be readable by the people who have to sign it, which a clause-numbered contract rarely is.

It is a summary and nothing more. The executed data processing agreement is the operative document, and where this page and that document differ, the executed document governs. Request the full agreement from info@denways.com before you rely on any of this in a procurement review.

The agreement is entered into alongside the terms of service and forms part of the same contractual relationship. It does not replace the privacy policy, which explains the same processing from the perspective of the individual whose data it is.

The customer is the controller. As the employer, it decides which employee data is collected, which modules are switched on, who inside the organization can see what, how long records are kept and what happens to them at the end. Those are the decisions that make an organization a controller, and none of them are ours.

Denways Technologies LLP is the processor. We process employee personal data on the customer's documented instructions and for no independent purpose of our own. We do not sell it, we do not use it to train models, and we do not market to a customer's staff off the back of it.

There is a narrow set of data where we act as controller in our own right: the contact details of the customer's administrators, billing records, and the website and enquiry data described in the privacy policy. That data sits outside this agreement and under the privacy policy instead.

The instructions we act on are the ones given through the platform by authorised administrators, plus anything set out in the agreement itself. If an instruction appears to require us to break the law, we will say so rather than carry it out.

The subject matter is the processing of personal data relating to the customer's employees, contractors and job candidates, to the extent needed to provide the DenwaysHR platform.

The duration runs for as long as the customer holds an active account, and then for the return or deletion period described below. Processing does not continue beyond that except where the customer's own retention obligations require records to be kept.

The nature of the processing is the ordinary set of operations a hosted platform performs: collection, storage, structuring, retrieval, calculation, transmission of generated files, backup, and eventual erasure. The purpose is to run the customer's HR, attendance, leave, payroll, performance and recruitment operations, and to keep the service secure and available while doing so.

Statutory outputs, including wage protection files and bank disbursement files, are generated by the platform on the customer's instruction and submitted by the customer. Responsibility for the accuracy and lawfulness of what is submitted rests with the customer as controller.

The exact fields depend on which modules the customer has enabled, so the list below is the outer boundary rather than a description of every account.

Categories of data subject: current and former employees, contractors and workers, job applicants, emergency contacts and dependants where the customer records them, and the customer's own administrative users.

We process personal data only on documented instructions, implement appropriate technical and organisational security measures, engage sub-processors only under the conditions set out below, assist the customer with data subject requests and with its own security and impact assessment obligations, notify personal data breaches without undue delay, and delete or return the data at the end of the relationship.

Personnel with access to customer data are bound by written confidentiality obligations that survive the end of their engagement. Access is granted on a least-privilege basis, tied to a named individual rather than a shared credential, and reviewed when a role changes.

Administrative access to production is limited to the people who need it to operate and support the service. Sensitive actions, including administrative impersonation of a user, role changes, salary changes and payroll disbursement, are recorded in an audit log naming who acted, on what, and when.

Personnel receive data protection and security awareness training appropriate to their role, and access is revoked promptly when someone leaves.

The technical and organisational measures we apply are described in full on the security page, and that description is incorporated into the agreement by reference rather than duplicated and left to drift out of date here.

In outline: the fields that would do the most harm if exposed, including bank account details and government identifiers, are encrypted at rest rather than merely placed behind an access check. Each organization's data is isolated at the database level, with Row-Level Security enforcing the boundary independently of the application, and an organization identifier supplied by a browser is never trusted to decide which organization's data is returned.

Sessions use HTTP-only, secure cookies, every cookie-authenticated request carries cross-site request forgery protection, authentication endpoints are rate limited, and uploads are scanned by an antivirus engine before they are trusted. Production sits behind a network edge providing managed firewall rules, denial-of-service protection and bot mitigation, and the origin accepts no direct public traffic.

We hold no ISO 27001 or SOC 2 certification. The controls above are in production and can be evidenced, but they have not been attested by an external auditor, and we will not describe them as certified.

We engage sub-processors to provide parts of the service we do not run ourselves, principally hosting, network edge security, transactional email, monitoring, subscription payment processing and file storage. The customer gives general authorisation for these on entering the agreement.

Each sub-processor is engaged under a written contract imposing data protection obligations no less protective than those in this agreement, and we remain fully liable to the customer for their performance.

The current categories, what each can access and why, are listed on the sub-processors page. Customers are notified before a new sub-processor is added and may object on reasonable data protection grounds within the notice window; where an objection cannot be resolved, the customer may terminate the affected part of the service without penalty.

Requests from employees to access, correct, delete, restrict, object to or port their personal data are the customer's to answer, because the customer decides what happens to its own records.

Much of the work is already done by the product. Employees have self-service access to their own attendance history, leave balances, payslips and personal record, and administrators can correct, export and delete records directly without needing us.

Where a request cannot be handled through the product, we assist by appropriate technical and organisational measures, taking into account the nature of the processing. If a request reaches us directly, we do not answer it ourselves; we pass it to the customer and tell the individual we have done so.

If we become aware of a personal data breach affecting customer data, we notify the affected customer without undue delay, and in any event within seventy-two hours of becoming aware of it.

The notification describes the nature of the breach, the categories and approximate number of data subjects and records involved, the likely consequences, the measures taken or proposed, and a contact point for further information. Where the full picture is not available at once, we send what we have and follow up rather than waiting until the investigation is complete.

Notifying a supervisory authority or the affected individuals is the customer's decision to make as controller. We provide the information the customer reasonably needs to make it and to meet its own deadline.

We maintain an internal record of breaches and the remedial action taken, and it is available to the customer on request.

On termination, and at the customer's choice, we return the customer's personal data or delete it. Export is available through the product throughout the term, so a customer does not have to depend on us to hold a copy of its own records.

Data is retained for a defined transition window after termination so the customer can complete its export, then deleted. Encrypted backups are not selectively edited; they age out on their existing rotation schedule and are then destroyed.

Deletion does not run ahead of the customer's own legal obligations. Employment, payroll and statutory records typically have to be kept for a period set by local labour law, and it is the customer as controller that determines what must be preserved.

We make available to the customer the information reasonably necessary to demonstrate compliance with the agreement, and allow for and contribute to audits conducted by the customer or an auditor it mandates.

In practice, most requests are satisfied by documentation: the security page, our description of technical and organisational measures, the sub-processor list, and answers to a security questionnaire. We would rather answer thoroughly on paper than turn every review into a site visit.

Where documentation is genuinely insufficient, an on-site or remote audit can be arranged on reasonable notice, at reasonable frequency, during business hours, and without disrupting the service or exposing another customer's data. An auditor may be required to sign a confidentiality undertaking, and audits beyond one a year may be chargeable at cost.

Our infrastructure and sub-processors may process personal data outside the country in which the customer operates. Where that happens, we rely on appropriate safeguards in our contract with each provider, and limit them to processing the data for the purposes we set.

Customers with a data residency requirement should raise it before signing rather than after, so we can tell you plainly what we can and cannot commit to for a given region. We would rather lose a deal on that point than commit to a residency guarantee we cannot honour.

The specific transfer mechanism relied on for a given customer, and the jurisdictions involved, are set out in the executed agreement.