Privacy Policy

This Privacy Policy explains how Kevin Alvarado, doing business as FTE Tracker, handles personal information in connection with the public FTE Tracker website, the public demonstration published on that website, and the hosted FTE Tracker application supplied to customer organizations.

Those are not the same product and this Policy does not treat them as one. Section 4 covers the Site and the Demo, where no visitor signs up, no visitor is identified, and nothing a visitor does is recorded on our servers. Sections 5 to 12 cover the Service, where personal data about an organization's workforce is processed on that organization's behalf and on its instructions.

This Policy is to be read together with the Terms of Service, the Data Processing Agreement and the Subprocessor List. Where the Data Processing Agreement and this Policy differ as to the handling of Customer Data, the Data Processing Agreement governs.

Last updated: 10 September 2026. This version takes effect on that date and replaces any earlier version.

The following terms are used with the same meaning in this Policy, in the Terms of Service, in the Data Processing Agreement and in the Subprocessor List.

FTE Tracker, we, us, our

Kevin Alvarado, a natural person doing business under the business name FTE Tracker. FTE Tracker is a sole proprietorship. It is not a corporation, a limited liability company or a partnership, and it has no parent, subsidiary or affiliated entity.

Service

The hosted FTE Tracker application supplied to a Customer under the Terms of Service, including time entry, supervisor approval, the quarterly Time & Effort certification workflow, administration and reporting.

Site

The public FTE Tracker marketing website.

Demo

The public demonstration published on the Site, which runs entirely inside the visitor's own web browser, requires no sign-up, and stores nothing on our servers.

Customer

An organization that has agreed with FTE Tracker to use the Service. Customers are organizations, not individuals.

Authorized User

An individual whom a Customer permits to use the Service, being an employee, supervisor, administrator or project manager of that Customer. The Terms of Service and the Data Processing Agreement call the same person a User; the two expressions mean the same thing.

Customer Data

All data that a Customer or its Authorized Users enter into, upload to, or generate within the Service, including all Personal Data contained in it.

Personal Data

Information relating to an identified or identifiable natural person. Where a United States state privacy statute applies, Personal Data is used in this Policy to include "personal information" as that statute defines it.

Controller and Processor

As defined in the EU and UK General Data Protection Regulation. For Customer Data, the Customer is the Controller and FTE Tracker is the Processor.

Business and Service Provider

As defined in the California Consumer Privacy Act as amended by the California Privacy Rights Act. For Customer Data, the Customer is the Business and FTE Tracker is the Service Provider.

Subprocessor

A third party engaged by FTE Tracker to process Personal Data contained in Customer Data. The current list is published at subprocessors.html.

PHI

Protected health information as defined at 45 CFR 160.103 under the Health Insurance Portability and Accountability Act.

FTE Tracker is operated by Kevin Alvarado, a natural person trading under the business name FTE Tracker, in the Commonwealth of Puerto Rico. He is the sole operator of the business and is personally responsible for the matters described in this Policy.

All privacy correspondence should be sent to privacy@ftetracker.com. That address is the only contact channel we publish for privacy matters. We do not publish a telephone number or a postal address for privacy correspondence.

We have not appointed a data protection officer, and we have not appointed a representative in the European Union or the United Kingdom. If a legal obligation to appoint either arises, we will do so and name them in this Policy.

Our role differs by context. For the Site and the Demo we are the Controller of the limited technical information described in section 4. For the Service we are a Processor and Service Provider acting for the Customer, as set out in section 5.

No account and no form. The Site contains no form and no form submission address. Every invitation to get in touch opens your own email program addressed to info@ftetracker.com. We receive nothing from a visit unless you choose to send that email.

No analytics and no tracking. We use no analytics service, no tracking pixel, no advertising technology, no session recording and no third-party profiling script on the Site, in the Demo or in the Service. We do not build profiles of visitors and we do not fingerprint devices. There is no advertising anywhere in what we publish.

The Demo runs on your own machine. The Demo requires no sign-up and creates no record on any server we operate. It signs you in automatically as a fictional administrator of a fictional organization and fixes the date so the sample reads correctly. The sample organization, its funds, its staff and their entries are invented; none of it describes a real person.

Everything you do in the Demo — entries you type, approvals you record, packages you build, any file you upload — is written only to your own browser's storage, listed in section 16. None of it is transmitted to us and we cannot see it. The Demo's Reset control erases the Demo's storage keys and deletes its browser database, and clearing your browser's site data has the same effect.

Typefaces are requested from Google. Every web page we publish — the Site, the Demo and the Service — requests the Inter typeface, and on the Site also Instrument Serif, from Google's font service at fonts.googleapis.com and fonts.gstatic.com. Making that request discloses to Google your IP address, your browser's user-agent string and the address of the page being loaded. We do not control what Google does with that information and we receive nothing back from it. This is the only disclosure to a third party that the Site and the Demo make, and we are the Controller of it.

One further request in the Service. Each load of the signed-in application also fetches the authentication client library from the public content delivery network cdn.jsdelivr.net, which discloses the same three items to that network. It receives no Customer Data. See section 9 and the Subprocessor List.

Server logs. We operate no visitor logging, no counter and no measurement of our own. The hosting provider that delivers our files necessarily processes your IP address and request details in order to deliver them, as every web host must. That provider is identified on request; see the Subprocessor List.

The Customer decides. The Customer organization determines the purposes and means of processing its workforce's Time & Effort data. It decides which people are enrolled, what the grant funds are, what an entry means, who approves it, what is certified and what is kept. In the language of the applicable statutes, the Customer is the Controller and the Business.

FTE Tracker acts. We store and process Customer Data on the Customer's instructions in order to provide, maintain, secure and support the Service. In the language of the applicable statutes we are the Processor and the Service Provider. We do not determine why or how Customer Data is processed.

We do not sell Customer Data. We do not share it for cross-context behavioural advertising. We do not use it for our own marketing, we do not use it to train machine-learning models, and we do not combine it with data from any other source.

What this means for an individual. If you are an employee, supervisor or administrator of a Customer, your employer — not FTE Tracker — decides what is recorded about you, who inside the organization can see it, and how long it is kept. If you want to see your records, correct them, ask why something was recorded, or object to it, contact your employer's FTE Tracker administrator or the person at your employer responsible for grant compliance.

If you write to us instead, we will not act on the request on our own account. We will refer it to your employer promptly and, where the employer instructs us, we will help carry it out. We do so because acting alone on an employer's records — disclosing them, changing them or deleting them — would itself be a use of the data we have no authority to make.

Because the Customer controls the account, a Customer's administrator can view and change records about its Authorized Users, and can act within the Service on behalf of another user. Where that happens the Service records both the identity of the person really signed in and the account they acted on behalf of.

The list below sets out the record types the Service holds and the fields in them, rather than a generic description. All of it is Customer Data and all of it belongs to the Customer.

For each Authorized User the Service holds: a system identifier; the identifier of the Customer organization; email address; first name; last name; role, being one of employee, supervisor, administrator or project manager; the email address of that person's supervisor, which identifies another person; contracted weekly hours; an active or inactive employment status flag; an optional photograph of the person, stored as an image embedded directly in the record; the date the record was created; and a flag indicating whether a password change is required at next sign-in. Most of these fields exist twice: in an account table used for sign-in and routing, and inside the Customer's own single data record used by the application.

For each Authorized User the Service holds the current allocation of that person's effort across grant funds as percentages, and a dated history of every previous allocation. Each version in that history records its effective date, the fund and percentage split, when it was created, and the email address of the person who created it. The record also holds any service group memberships and any week-by-week override of contracted hours.

Each entry records: an identifier; the work date; the duration in minutes; start time, end time and break minutes, which the current interface leaves empty; the grant fund, service group and activity the time was charged to; where the entry is leave rather than work, the leave type; a free-text note typed by the person; the entry's status, being pending, approved, rejected or locked; who reviewed it, when, and any note the reviewer wrote; the email address of an administrator who saved it; the fund and percentage split that was in effect on that date; the grouping of blocks saved together on one day; the times the entry was created and last updated; where an approved entry was reopened, the reason, who reopened it, when, how many times, and the history of those reopenings; and where an administrator filed the entry on someone else's behalf, that fact, who did it, when, and for whom.

Two points about entries deserve stating plainly.

• The note is free text. It is an open field and the Service cannot control what is typed into it. The Customer is responsible for instructing its workforce what may and may not be entered there. PHI must never be entered; see section 13.
• A leave entry is an absence record. Where an entry records leave, it records that a named individual was absent on a named date under a named leave type, which may be a sick day. Customers should treat those records as sensitive workforce records and restrict administrative access accordingly. The Service must not be used to record any clinical detail, diagnosis or treatment alongside them.

An approval is recorded as a change to the entry together with an audit record. Between them they hold the identity of the reviewer, the exact time of the decision, the decision itself, any note the reviewer wrote about that employee's hours, and the values of the record both before and after the change. Where a decision is undone, that is recorded too.

Each package records: the quarter it covers; the email address of the certifying supervisor; its status; one line per covered employee giving that employee's email address, a reference to their signed certification file, who uploaded it and when, and its version; when the package was generated, submitted and approved and by whom; each submission, including the exact attestation text the supervisor agreed to, their identity and the exact time; and a permanent record of every send-back or rejection.

The Service writes an audit record for each change. Each record holds: a sequence number; the local time of the change with its offset from Coordinated Universal Time; the organization's time zone and the browser's offset at that moment; the email address of the person really signed in; where an administrator was acting on behalf of another user, that person's email address; the action, such as creating, editing, approving, reopening or importing an entry, changing a person's role, supervisor, hours, allocation, groups, photograph or status, resetting a password, or creating, submitting, approving or sending back a certification package; what was touched; and a snapshot of the record's values on both sides of the change.

Two honest qualifications. The log holds the most recent five thousand records; when that limit is reached the oldest records are dropped and a count of dropped records is kept, so it is not a complete permanent history. And no part of the application edits or deletes an existing record, but that is a property of the application rather than of the database beneath it; see clause 12.6.

If you write to help@ftetracker.com we hold your name, your email address and the content of your message, in order to answer you and to keep a record of what was asked and agreed. We hold that correspondence as Controller, not as Processor.

The Service collects no analytics, no advertising identifier, no location data, no biometric template and no device fingerprint. The Settings screen reads your browser's user-agent string in order to display a readable description of your device back to you; that string is not stored by the application and is not transmitted to us.

Signing in to the Service requires an email address, a password, and a six-digit code from an authenticator application. All three steps are handled by the authentication service operated by our subprocessor Supabase.

Passwords. The password you type is submitted over an encrypted connection to that authentication service, which is responsible for storing and verifying it. Our application does not store it, and the password field is cleared as soon as it is accepted. We cannot read your chosen password and we cannot read any hash of it. Both exist only inside the authentication service's own account store, which our application never reads. The account table our application does read contains no password material of any kind.

Changing a password. When you change your password the current one is verified over a separate connection that is deliberately configured not to persist anything, so that your fully authenticated session is not weakened, and the new password is then set through the authentication service. The application requires at least ten characters; the authentication service applies its own policy in addition.

New accounts. When an administrator creates an account, it is created on the server by a privileged function and a randomly generated twelve-character temporary password is returned once, to that administrator's screen, for them to pass to the new user. That temporary password passes through the administrator's browser at that moment. It is not stored by the application and it is not emailed to anyone: the account is created already confirmed, so no confirmation message is sent.

One exception we would rather disclose than gloss over. A path inherited from the standalone version of the application, used when an administrator resets another user's password, derives a value from a temporary password using PBKDF2-HMAC-SHA256 with one hundred thousand iterations and a random per-user salt, and writes that derived value into the Customer's data record. It does not contain the password, and it is not used to authenticate anyone in the Service. It is nonetheless password-derived material stored where it should not be, and it is being removed. We state it here rather than claim, without qualification, that no password material is ever written to a Customer's record.

Authenticator codes. The shared secret behind your six-digit code is generated by the authentication service and held in its factor store on the server. During enrolment the secret exists briefly in the enrolling browser so that the QR code and the manual-entry string can be shown to you; it is held only in a page variable, is discarded when you switch accounts or leave the page, and is never written to browser storage, to the browser database, or to the Customer's data record. Our application cannot read an existing user's secret. It can see only that a factor is registered and when it was registered.

There are no recovery codes. The Service does not issue recovery codes. None are generated, transmitted or stored, and any screen that mentions them will tell you they are not switched on. If a user loses their authenticator, the registered factor must be removed by hand at the request of the Customer's administrator; the administrator should write to help@ftetracker.com. We act on that request only for a Customer administrator, never on the request of the affected user alone.

Your session. After a successful sign-in the authentication library stores your session — an access token, a refresh token and your account record — in your browser's local storage, listed in section 16. Entry to the application requires that the session has completed the second factor, both at sign-in and each time a session is resumed. Signing out from the sign-in screen ends only that local session; a full sign-out ends the session everywhere.

Customer Data. We process Customer Data only to provide, maintain, secure and support the Service, to prevent and investigate abuse of it, and to comply with law. We act on the Customer's documented instructions, which are the Terms of Service, the Data Processing Agreement, the Customer's configuration of the Service and any further written instruction the Customer gives us. The legal basis for that processing is the Customer's, as Controller; the Customer is responsible for having one and for giving its own workforce the notice its law requires.

The Site and the Demo. The only processing we carry out as Controller is delivering the pages you request and the typefaces they use, which discloses the technical information described in clause 4.4. Where the General Data Protection Regulation applies, our legal basis is our legitimate interest in presenting a website and serving the content it was asked for; there is no analytics or advertising purpose to weigh against you.

Correspondence. We process the messages you send us in order to answer them, to negotiate and administer agreements, and to keep a record. Where the General Data Protection Regulation applies, the basis is our legitimate interest in running the business and, before a contract, taking steps at your request.

Which law frames this Policy. FTE Tracker is operated from the Commonwealth of Puerto Rico and the Service is offered to United States organizations that administer federal awards. The governing frame is therefore United States federal and state law, not the General Data Protection Regulation. We address the Regulation here for completeness, and the Data Processing Agreement contains processor terms for a Customer to which it does apply, but nothing in this Policy should be read as a representation that we are established in, or that we target, the European Union or the United Kingdom.

Service Provider commitments. Under the California Consumer Privacy Act as amended, we are a Service Provider. We do not sell Personal Data and we do not share it for cross-context behavioural advertising. We do not retain, use or disclose Personal Data for any purpose other than performing the Service and the purposes permitted by that statute, and we do not combine it with Personal Data received from any other source.

Personal Data in Customer Data is disclosed only in these cases.

• To the Customer and its Authorized Users, in accordance with the Customer's own configuration of the Service and the qualification in clause 12.6.
• To the subprocessors listed at subprocessors.html, each of which performs a defined function. Only one of them receives Customer Data, and it is engaged on its own published data processing terms. The others receive no Customer Data at all: they receive only the technical information described in clause 9.4, and they are used on their published public terms of service, which is what the Subprocessor List says of each.
• Where we are legally compelled, on the terms of clause 9.2.
• On the Customer's written instruction, to a recipient the Customer names.

Legal compulsion. If we receive a subpoena, court order, warrant or other binding demand for Customer Data, we will disclose only what the demand actually requires. Unless we are legally prohibited from doing so, or there is a credible risk to a person's life or safety, we will notify the affected Customer before we disclose anything, so that the Customer can seek protection from the issuing authority, and we will give the Customer a reasonable opportunity to do so. Where we may lawfully object or narrow the demand, we will consider doing so. We do not volunteer Customer Data to anyone.

No sale, no sharing, no advertising. We do not sell Personal Data. We do not share it for advertising of any kind. We do not use data brokers, advertising networks or measurement providers, and none of our surfaces contains their technology.

Delivery-related disclosures. Google's font service, on every surface, and the jsDelivr content delivery network, in the Service, each receive the IP address, user-agent string and referring page of the browser making the request, because that is inherent in requesting a file from them. Neither receives Customer Data. Both are listed at subprocessors.html so that a Customer can see them.

Transfer of the business. If the business operated as FTE Tracker is sold or transferred, Customer Data may transfer with it. We will notify each affected Customer in advance, the transferee will be bound by the Data Processing Agreement, and a Customer that objects may terminate and require deletion of its Customer Data under section 11.

FTE Tracker is operated from the Commonwealth of Puerto Rico, a territory of the United States. The Service is built for organizations that administer United States federal awards and is offered to them.

If you use the Service or visit the Site from outside the United States, your information will be processed by the providers listed at subprocessors.html, in the locations described there. Content delivery networks and font services serve files from an edge location near the visitor, so those requests are not confined to one country.

Where a Customer requires transfer terms under the General Data Protection Regulation or the United Kingdom's data protection law, those terms are addressed in the Data Processing Agreement rather than in this Policy.

During the agreement. While a Customer's agreement is in force, the Customer decides what is kept and what is removed. We do not delete Customer Data on our own initiative.

Earlier deletion on request. A Customer may require deletion earlier than that. The request must be made in writing to privacy@ftetracker.com by an administrator authorised by the Customer. We will confirm the request with the Customer, carry out the deletion within thirty (30) days of that confirmation, and confirm in writing when it is done. A Customer that asks for early deletion should satisfy itself first that it has met its own retention obligations, because the deletion cannot be undone.

Deleting one person. When a Customer's administrator deletes an Authorized User, the Service removes that person's record, their entries and their notifications from the Customer's data record. Records in the event log that name that person by email address remain, because the event log is the audit trail the Service exists to produce and removing entries from it would destroy its purpose. The sign-in account itself is removed separately, by us, at the Customer's written request.

Deletion requests can collide with federal retention. The certifications the Service produces are federal award records the Customer is required to keep. A request from an individual to erase their records may therefore conflict with the Customer's own legal obligations. That judgment belongs to the Customer as Controller. We act on the Customer's instruction and will tell the Customer where an instruction appears to conflict with a legal requirement we are aware of.

Backups. We operate no backup system of our own. Backups are a function of the database platform described at subprocessors.html, and where a record is deleted, copies may persist in that platform's backups until they expire in the ordinary course.

Signed certifications. Signed certification files are held in the browser that uploaded them and are not retained by us at all; see clause 6.7. They are outside the retention periods above because we never hold them.

This section states the measures that are actually in place. It deliberately does not claim measures we do not have, and it sets out the limits of the ones we do.

In transit. Every endpoint of the Service is served over HTTPS. Transport encryption is terminated by the platform providers listed at subprocessors.html rather than configured by our own code.

At rest. Customer Data is stored in a managed database operated by our database subprocessor, and encryption at rest is a property of that platform rather than something our code performs. We apply no additional application-level or field-level encryption: within the database, a Customer's data record is stored as structured text.

Multi-factor authentication. A six-digit authenticator code is required to enter the application, both at sign-in and when a session is resumed. A password alone does not open the application.

Separation between Customers. Each Customer's data is held in a row identified by that organization's identifier. Separation between organizations is enforced inside the database by PostgreSQL row-level security: the account table, the organization table and the data table each carry a policy comparing the row's organization identifier with the organization resolved from the signed-in account's own record, and row-level security denies access by default where no policy matches. Account creation is performed by a server-side function that derives the organization from the caller's own record rather than from anything the caller sends, requires a fully authenticated session and an administrative role, and uses a privileged key that exists only as a server-side setting and never reaches a browser.

That is a description of the mechanism we have built, not a guarantee about it. We do not represent that this or any other measure in this Policy is free of defect, and clause 12.9 applies to all of them.

What separation does not mean inside one organization. Customers should understand three things before issuing accounts.

• Every Authorized User of an organization can read every colleague's account record in that organization — names, email addresses, roles and photographs. The Service needs this for the organization chart and for choosing supervisors.
• The rule that an employee sees their own entries, a supervisor sees their direct reports and an administrator sees everyone is applied by the application interface. It is not a boundary inside the database. At the database layer, the organization's whole data record is readable and writable by any signed-in member of that organization. A Customer should treat every account it issues as an account with access to the organization's whole Time & Effort record and manage the issue and removal of accounts on that basis.
• For the same reason, the event log should be understood as an audit trail maintained by the application, not as a tamper-proof record.

A session that has completed the password step but not yet the six-digit code can read the names, email addresses and roles of that organization's members, because the sign-in screen has to show the user whom to contact for help. This is deliberate and we state it rather than describe the Service as showing nothing before the second factor.

Attribution. Where an administrator acts on behalf of another user, the event log records both the real actor and the account acted upon, and changing a password is blocked while doing so.

No certification. FTE Tracker holds no SOC 2 attestation and no HIPAA certification. We have not undergone an independent security audit. Nothing in this Policy, on the Site or in any proposal should be read as a claim to either, and we will not represent otherwise to a Customer or a funder.

No service is completely secure. The measures above reduce risk; they do not eliminate it. A Customer's own controls — who is given an account, how promptly leavers are removed, and how administrators are chosen — matter at least as much as ours.

If something goes wrong. Where we become aware of a personal data breach affecting a Customer's Customer Data, we notify that Customer's administrators and billing contact without undue delay and in any event within seventy-two (72) hours of becoming aware of it, with the information set out in clause 11 of the Data Processing Agreement. As Controller, the Customer decides whether to notify a regulator, a funder, an insurer or the affected individuals; we assist with that and do not make those notifications for the Customer unless it instructs us in writing. If you believe you have found a security problem in anything we publish, write to security@ftetracker.com and describe it; we will not pursue a researcher who reports a problem in good faith and does not access, alter or retain another person's data.

Nothing in this Policy, the Terms of Service or the Data Processing Agreement creates a business associate relationship, and no course of dealing, purchase order or funder questionnaire will create one.

Entering PHI into the Service is a breach of the Terms of Service. The Customer is responsible for the consequences of doing so, including any obligation it may have under HIPAA arising from that disclosure.

If we become aware that PHI has been entered, we may require the Customer to remove it promptly, and may suspend the affected part of the Service until it is removed.

Recording that a person took leave of a given type on a given date is workforce absence information, which the Service is designed to hold. It must not be extended into diagnosis, treatment, clinical notes, or any information about a patient, client or member served by the Customer.

If your data is in the Service, start with your employer. Depending on where you live, you may have rights to know what is held about you, to obtain a copy, to have inaccurate data corrected, to have data deleted, to restrict or object to processing, to receive data in a portable form, and not to be treated worse for exercising any of them. Those rights are exercised against the Customer as Controller. Contact your employer's FTE Tracker administrator.

What we do. On the Customer's instruction we will provide, correct, export or delete records so the Customer can answer a request, and we will do so within the time the Customer needs to meet its own deadline. If a request reaches us directly, we will pass it to the Customer promptly and tell you that we have, without acting on it ourselves.

Data we hold as Controller. For anything we hold in our own right — correspondence sent to us, and the technical information described in clause 4.4 — write to privacy@ftetracker.com. In practice this is a small amount of data: the Site and the Demo generate no record of you on our systems at all.

We may need to verify that a request comes from you, or from someone entitled to act for you, before we act on it. We will not ask for more information than that verification requires, and we will not use what you give us for verification for any other purpose.

We do not use Personal Data for automated decision-making that produces legal or similarly significant effects. The Service produces figures and documents; the decisions about a person are made by the people at the Customer who read them.

If you are not satisfied with how a request was handled, you may complain to your state attorney general or other competent authority, or, where the General Data Protection Regulation applies, to a supervisory authority in your country. We would rather you told us first, at privacy@ftetracker.com.

The Service is a workplace tool licensed to organizations for use by their workforce. It is not directed to children, we do not market it to children, and we do not knowingly collect Personal Data from a child.

Customers must not use the Service to record information about children. A Customer that is a school or a youth-serving organization must use the Service only for its own staff, not for its students or the young people it serves.

If we learn that information about a child has been entered into the Service, we will notify the Customer and require its removal. Where we hold such information as Controller — for example in correspondence — we will delete it.

We set no cookies. Neither the Site, nor the Demo, nor the Service sets a cookie of any kind. There is no advertising cookie, no analytics cookie and no session cookie, and there is therefore no consent banner: apart from the font request described in clause 4.4, there is nothing to consent to.

What we do use is your browser's own storage, on your own machine, for the purposes below. Nothing in this table is transmitted to us except the session token, which is sent back to the authentication service to keep you signed in.

The browser database. A database named fte-files, with a store named pdfs, holds signed Time & Effort certification files — the file itself, its name and the time it was uploaded. It exists in the Service and in the Demo. In the Service it is the only place a signed certification exists, as clause 6.7 explains. Those files contain the employee's name, hours, fund allocation and signature.

Session storage is not used by any of our surfaces.

Clearing it. You can clear all of the above from your browser's settings at any time. The Demo's Reset control clears the Demo's keys and deletes the browser database. Be aware that clearing storage while using the Service signs you out and permanently destroys any signed certification files held in that browser, which cannot be recovered from us.

We may revise this Policy. The current version is always published at this address with the date it was last updated at the top.

Where a change is material and affects the Service, we will notify each Customer's designated administrator by email at least thirty (30) days before it takes effect. A change that is not material — correcting a reference, clarifying wording that does not alter its meaning — takes effect when it is posted.

Changes to the list of subprocessors are notified as set out at subprocessors.html, not under this section.

We will not apply a revision retroactively to reduce the protection given to Personal Data already collected, unless the affected Customer agrees in writing or the law requires it.

This Policy and any dispute arising out of it are governed by the laws of the Commonwealth of Puerto Rico, without regard to its conflict of laws rules, and the courts sitting in the Commonwealth of Puerto Rico are the exclusive venue, as set out in the Terms of Service.

Nothing in this clause deprives an individual of a right to bring a claim, or to complain to an authority, in a place where the law gives them that right regardless of contract.

Write to privacy@ftetracker.com. Putting the word Privacy in the subject line helps it reach the right place quickly.

Kevin Alvarado, doing business as FTE Tracker, Commonwealth of Puerto Rico. This is the only contact address we publish for privacy matters.

If you are an employee, supervisor or administrator of an organization that uses the Service and your question is about your own records, clause 5.4 explains why your employer is the right first stop.