=========================================================================
PRIVACY POLICY
DMS-IA — Digital Memo System Industrial Automation
================================================================================
Document Title : Privacy Policy — DMS-IA Digital Memo System Industrial Automation
Developer / Owner: Rohmit Neelakant Shirgoppi (Aadhaar: Neelkant Shirgoppi)
Contact Email : romit232091@gmail.com
Phone : +91-9535835504
Address : H.No. 522, Near CSI Church, Teachers Colony Road,
Township, Dandeli — 581325, Karnataka, India
Effective Date : 01 June 2026
Last Updated : 19 July 2026
Policy Version : 2.7 — Updated for current codebase. All gaps closed.
CHANGE LOG v2.6 → v2.7 (19 July 2026):
- UPDATED Section 8A.2 and Section 23: Named admin@yourdigiemployee.com
explicitly as the address Licence Administration Data is emailed to, and
disclosed it as the same address the Software's own trial-ending and
licence-expired messages direct administrators to contact — correcting a
prior gap where only romit232091@gmail.com was named anywhere in this
Policy despite the product itself using a different address operationally.
- UPDATED Sections 9 and 12: Disclosed that, as of DMSLIB_1_v29, every
deployment's Cloudinary attachments are namespaced under a distinct,
non-reversible per-deployment folder within the shared vendor account
(derived from a one-way hash of the deployment's spreadsheet ID), as a
defense-in-depth measure against attachments from different
organisations being stored in one undifferentiated namespace.
CHANGE LOG v2.5 → v2.6 (19 July 2026):
- CORRECTED Section 2.2 and multiple other sections: the Software's attachment
feature was upgraded to a direct browser-to-Cloudinary upload (photos,
video, one other document) as the primary attachment method. Legacy Google
Drive links remain supported. This policy previously stated that DMS-IA
"does not support direct file uploads" and that attachments were "Drive
link only" — this is no longer accurate and has been corrected throughout,
including Sections 3.6, 4, 5, 8, and Schedule-equivalent sections.
- ADDED Section 2.4: Cloudinary — Attachment Storage Provider.
- REWRITTEN Section 3.6: File Attachments now describes direct Cloudinary
upload as the primary method, with size/count limits, the shared vendor
account model, the 3-day automated retention/deletion job, and the
per-organisation Cloudinary override option.
- ADDED Section 8A: Licence Administration Data — full disclosure that the
Developer receives limited data (organisation name, administrator email,
spreadsheet ID) at initial setup, recorded in a Developer-controlled
Licence Register, for licence tracking and renewal billing purposes only.
This corrects the prior blanket claim that "the Developer does NOT access,
view, collect, or store any of your personal data at any time" and that
"Developer Servers: NOTHING — BY DESIGN. No Developer infrastructure
exists" — both of which omitted this licence administration data flow.
- UPDATED Section 8: External Request scope description now also covers
Cloudinary Admin API calls used to delete expired attachments.
- UPDATED Section 9: Added Cloudinary as a disclosed sub-processor, with
full data/retention/safeguards disclosure.
- UPDATED Section 10: Added Cloudinary and Developer's Licence Register as
data stores; corrected the "Developer Servers: NOTHING" statement.
- UPDATED Section 11: Corrected "With the Developer — NONE" to accurately
reflect Licence Administration Data and Cloudinary attachment storage.
- UPDATED Section 26: Added Cloudinary/AWS cross-border transfer disclosure
(new 26.4); renumbered subsequent subsections; corrected Section 26.2.
- UPDATED Section 28 (Machine-Readable Summary): corrected several answers
that are no longer accurate given the above changes (data access, sub-
processor list, international transfer, direct file upload support).
CHANGE LOG v2.4 → v2.5 (29 June 2026):
- REMOVED Section 6.5: Gmail Sent Folder Access — GmailApp.search() was
removed from the codebase. DMS-IA no longer reads Gmail Sent folder.
LINK 1 / LINK 2 columns now store "SENT" (plain text status label) not
a Gmail thread URL. No gmail.readonly scope is used.
- UPDATED Section 8: Google API Limited Use Disclosure
- Replaced "Gmail API (GmailApp)" with "Gmail API (MailApp)" — DMS-IA
uses MailApp exclusively (script.send_mail scope only). GmailApp is
not used anywhere in the codebase.
- REMOVED Google Forms API (FormApp) entry — DriveApp and FormApp
are not used in the current codebase. The Official Memo form is now
a built-in HTML web page (HtmlService), not a Google Form.
- REMOVED Google Drive API (DriveApp) entry — Drive folder creation
and file upload through DriveApp has been removed. File attachments
are now shared via Google Drive public link entered manually by the
submitter. Drive is accessed only via UrlFetchApp (no Drive scope).
- ADDED api.qrserver.com external fetch entry for QR code generation.
- UPDATED HtmlService entry — now covers Official Memo HTML form
(including CC DP-01 live lookup), in addition to Call Memo pages.
- UPDATED Section 3.5: Memo Content — Context / Message field is now
MANDATORY (not optional) on the Official Memo HTML form. The submitter
cannot submit without completing this field.
- UPDATED Section 3.6: File Attachments — now entered as a Google Drive
public link (text field) rather than a file upload via Google Form.
- UPDATED Section 5: Data Minimisation — corrected Context character
limit to 3,000 characters (was stated as 2,000 in v2.4).
- UPDATED Section 9: Sub-processors — added api.qrserver.com as a
limited sub-processor for QR code image generation (no personal data
sent; only the deployment URL is transmitted).
- UPDATED Section 10: Data Storage — QUEUE sheet now also covers Official
Memo web form submissions (previously Google Form only).
- UPDATED Section 12: Security — added CC DP-01 live validation via
CHECKDP endpoint; added CSP-compliant HTML (no inline event handlers).
- UPDATED Section 28: Machine-readable — all v2.5 changes reflected.
CHANGE LOG v2.3 → v2.4 (18 June 2026):
- Added Section 25: Data Protection Officer Statement (GDPR Art.37)
- Added Section 26: Cross-Border Transfer Mechanisms (GDPR Ch.V)
- Added Section 27: Consent Withdrawal Mechanism (DPDPA S.6)
- Updated Section 23: Grievance timeline made legally binding with remedy
- Updated Section 15: Explicit consent withdrawal procedure added
- Updated Section 24: Machine-readable updated for all v2.4 additions
CHANGE LOG v2.2 → v2.3 (18 June 2026):
- Updated Section 3.4: Added designation data from WORKER LIST Col D
- Updated Section 5: Added 30-person limit as data minimisation measure
- Updated Section 6.13: Added confirmation email sent after Call Memo submission
- Updated Section 10: Added CALL MEMO sheet and QR CODE sheet
- Updated Section 14: Added cleanupExpiredOtpKeys daily automated deletion
- Updated Section 24: Machine-readable entries updated
CHANGE LOG v2.1 → v2.2 (18 June 2026):
- Added Section 3.8: OTP Authentication Data (Call Memo HTML page)
- Added Section 3.9: Reason for Overtime (new form field)
- Updated multiple sections for OTP and Call Memo additions
Copyright Diary : SW-25725/2026-CO — Filed 01/06/2026, Copyright Office,
Government of India
Applicable Laws : DPDPA 2023 (India) · IT Act 2000 · IT Rules 2011 · GDPR (EU)
CCPA (California) · Google API Limited Use Policy
Google Workspace Marketplace Policies
================================================================================
1. INTRODUCTION AND SCOPE
================================================================================
This Privacy Policy ("Policy") governs the collection, use, storage, processing,
transfer, and protection of personal data by DMS-IA — Digital Memo System
Industrial Automation ("DMS-IA", "the Software", "the System"). DMS-IA is
developed, owned, and maintained by Rohmit Neelakant Shirgoppi ("Developer",
"we", "us").
DMS-IA is a Google Apps Script-based software product deployed within an
organisation's own Google Workspace account. It provides digital memo submission,
routing, approval, escalation, and audit trail capabilities exclusively for
internal organisational use. It also provides a dedicated Call Memo HTML web
application accessible via QR code for direct worker submission, and an Official
Memo HTML web application for internal staff. If you are using DMS-IA, your
organisation has purchased a licence from the Developer and has deployed the
system within their own Google account.
This Policy applies to all natural persons whose personal data is processed by
DMS-IA — memo submitters, Call Memo submitters, approvers, CC recipients,
department heads, managers, system administrators, and any other person whose
data enters the system.
This Policy satisfies the requirements of: Google Workspace Marketplace Programme
Policies, Google API Services User Data Policy (Limited Use), DPDPA 2023 (India),
IT Act 2000, GDPR (EU), CCPA (California), and automated AI-based compliance
scanners. This Policy should be read in conjunction with the DMS-IA Software
Licence Agreement and Terms of Service ("Agreement"), which is incorporated
herein by reference. Please read this policy carefully. If you have any
questions, contact romit232091@gmail.com.
================================================================================
2. DATA CONTROLLER, PROCESSOR, AND DEVELOPER ROLES
================================================================================
2.1 The Deploying Organisation — Primary Data Controller
---------------------------------------------------------
The organisation that licences and deploys DMS-IA within their Google Workspace
account is the primary Data Controller. They determine purposes and means of
processing, manage access, set retention periods, and bear full DPDPA/GDPR
compliance responsibility toward their employees and stakeholders.
2.2 The Developer — Not a Data Controller or Processor for Operational Data
------------------------------------------------------------------------------
Rohmit Neelakant Shirgoppi (Developer) is the software author only. The
Developer does NOT access, view, collect, or store any memo, HR, or other
operational personal data generated by your use of DMS-IA's workflow, at any
time. All such data stays within your organisation's Google Sheets and Gmail,
which your organisation controls. The Developer receives zero telemetry,
analytics, usage logs, or memo content from any deployment.
This is subject to two limited, fully-disclosed exceptions, described in full
in Section 8A and Sections 3.6/9/10 respectively:
(a) Licence Administration Data — a small set of account-level data
(organisation name, administrator email, spreadsheet ID) transmitted to
the Developer once, at initial setup, purely for licence tracking and
renewal billing; and
(b) Attachment Storage — by default, file attachments voluntarily uploaded
by users are stored temporarily on a Developer-administered Cloudinary
account (see Section 2.4), until automatically deleted.
Neither exception gives the Developer access to memo content, HR records, or
any other operational data of your organisation.
2.3 Google — Infrastructure Provider
--------------------------------------
Google LLC provides the underlying platform (Google Sheets, Gmail, and Google
Apps Script). Google processes data under its own Privacy Policy and Workspace
Terms. The Developer has no control over Google's data handling. If you have
questions about how your organisation uses your data within DMS-IA, please
contact your organisation's administrator or HR department directly.
2.4 Cloudinary — Attachment Storage Provider
-----------------------------------------------
Cloudinary provides the third-party cloud storage used, by default, to store
file attachments (photographs, videos, and documents) that Authorised Users
voluntarily upload through the Official Memo Module. Cloudinary processes this
data under its own privacy policy and Data Processing Agreement. The Developer
does not control Cloudinary's infrastructure, but does administer the account
credentials used by DMS-IA, including the automated deletion of attachments
after the retention period described in Section 3.6. Full disclosure of this
data flow is at Sections 3.6, 9, 10, and 26.4.
================================================================================
3. PERSONAL DATA COLLECTED — COMPLETE INVENTORY
================================================================================
DMS-IA collects and processes only the following categories of personal data.
This is the complete and exhaustive inventory — no other data is collected.
--------------------------------------------------------------------------------
3.1 Email Address
--------------------------------------------------------------------------------
What it is:
Your Google account email address (e.g. yourname@gmail.com or
yourname@yourcompany.com).
How it is collected:
(a) Automatically retrieved when you submit a memo through the Official Memo
HTML web form (the system reads it from your session), or when your
organisation's administrator enters it into the system during setup.
(b) Retrieved automatically from the TO sheet when you enter your DP-01
number on the Call Memo HTML page. You do not type your email — the
system fetches it from your registered record and pre-fills it read-only.
Why it is used:
- To identify you as the person submitting a memo
- To send you a one-time OTP magic link for Call Memo authentication
- To send you a confirmation email when your memo is submitted
- To send you a notification email when your memo is approved or rejected
- To verify your identity as the designated approver before processing your
approval or rejection decision
- To send you a reminder or escalation alert if a memo requires your attention
- To record your action in the permanent audit log
- To temporarily store in Google's secure cache for duplicate submission
prevention for 60 seconds and for cryptographic token verification for up
to 6 hours
How long it is kept: As determined by your organisation's data retention policy.
--------------------------------------------------------------------------------
3.2 DP Number (Department Position Number)
--------------------------------------------------------------------------------
What it is:
A unique identification number assigned to your position within your organisation
(e.g. DP001 or ELE-02).
How it is collected:
(a) Entered by your organisation's administrator during system setup in the FROM
or TO configuration sheet.
(b) Entered by you on the Call Memo HTML page DP-01 field to initiate OTP
authentication. The DP-01 field on the Call Memo form itself is pre-set to
0000 (the recipient's DP) and is non-editable.
(c) Entered by you on the Official Memo HTML form in the "Your DP-01" field,
or auto-populated if your session is already authenticated.
Why it is used:
- To match your submission to your department and position in the system
- To look up your registered email address from the TO sheet for OTP delivery
- To identify and route the memo to the correct approver for your department
- To identify you as the CC recipient when applicable
- To display your department position in the memo record
- To perform live validation (CHECKDP lookup) when a submitter enters a
Receiver DP-01 or CC DP-01 on the Official Memo form
How long it is kept: As determined by your organisation's data retention policy.
--------------------------------------------------------------------------------
3.3 Department Name
--------------------------------------------------------------------------------
What it is:
The name of the department you belong to (e.g. Civil, Electrical, Mechanical,
or Administration).
How it is collected:
Entered by your organisation's administrator during system setup.
Why it is used:
- To display the sender and recipient department clearly in all memo emails
- To route escalation alerts to the correct department head or manager when
a memo is not actioned within the configured time limit
- To group and display memo statistics by department in the Command Centre
- To identify the correct escalation authority for your department
- To populate the department dropdown in the Call Memo HTML form
How long it is kept: As determined by your organisation's data retention policy.
--------------------------------------------------------------------------------
3.4 Full Name and Job Designation
--------------------------------------------------------------------------------
What it is:
Your full name and job designation as entered by your organisation's administrator
(e.g. Rajesh Kumar / Engineer, Sunil Sharma / Technician).
How it is collected:
(a) Entered by your organisation's administrator during system setup in the
WORKER LIST sheet (Col B = Name, Col D = Designation).
(b) Retrieved automatically from the WORKER LIST sheet by the server when you
are selected as a person involved in a Call Memo. You do not type your name
or designation — the backend looks them up using your DP number to ensure
accuracy and eliminate URL-length data loss.
(c) Retrieved from the FROM sheet for Official Memo submitters by matching
your email address.
Why it is used:
- To display your name and designation professionally in all memo emails
- To identify you as the approver or rejector in decision confirmation emails
- To display your name in the PDF memo document under the Authorization section
- To record your name in the permanent audit log alongside your actions
- To display in the Call Memo people list in the format:
Name (DP:ELE001, Designation) when a submitter selects you
- To display in the Official Memo preview panel and in the live receiver name
lookup when a submitter enters a DP-01
How long it is kept: As determined by your organisation's data retention policy.
--------------------------------------------------------------------------------
3.5 Memo Content and Rejection Reasons
--------------------------------------------------------------------------------
What it is:
The content of memos you submit, including Subject, Context / Message (mandatory),
Priority, Action Required fields, and any rejection reason typed by the approver.
How it is collected:
Entered by you through the Official Memo HTML web form at the time of submission,
or typed by the approver in the rejection comment box.
IMPORTANT — Context / Message is Mandatory:
The Context / Message field is a required field on the Official Memo HTML form.
The form will not submit without it. This is a deliberate policy choice to ensure
every memo has adequate context for the approver.
IMPORTANT — Licensee Responsibility Regarding Sensitive Data:
The deploying organisation is responsible for ensuring that employees do not
include sensitive personal data — such as health information, financial details,
personal identification numbers, or third-party personal data — in memo content
fields. DMS-IA stores whatever content is submitted without filtering. The
organisation must inform their employees accordingly.
How long it is kept: As determined by your organisation's data retention policy.
--------------------------------------------------------------------------------
3.6 File Attachments (Optional)
--------------------------------------------------------------------------------
What it is:
A photograph, video, or one other document voluntarily attached by the
submitter through the Official Memo HTML form's built-in attachment uploader.
A legacy Google Drive public sharing link is also still accepted for
backward compatibility.
How it is collected:
For a new upload, the file is sent directly from the submitter's own browser
to Cloudinary (a third-party cloud storage provider — see Sections 2.4 and
9), using an unsigned upload preset. DMS-IA's own server-side code never
sees or handles the raw file bytes during upload. Cloudinary returns a
delivery URL for the uploaded file, and only that URL is stored in the
MASTER MEMO sheet. Where a legacy Drive link is used instead, the submitter
enters the link as text and DMS-IA does not upload, store, or access the
file itself.
Size and count limits: up to a configured number of photographs (each up to
10 MB), one video (up to 100 MB), and one other document, per memo. Images
are automatically compressed in the browser before upload where this
reduces file size, to conserve storage.
Why it is used:
To provide supporting documentation for the memo. DMS-IA displays the
attachment link to the approver in the approval email and in the MASTER
MEMO record.
IMPORTANT — Cloudinary is a Third Party:
By default, all deployments of DMS-IA share a single Developer-administered
Cloudinary account. This means uploaded attachment files are, by default,
stored outside your organisation's own Google Workspace account, on
Cloudinary's infrastructure, until automatically deleted (see below). An
organisation may instead configure its own Cloudinary account (via Script
Properties) so its attachments are stored under an account it controls
instead of the shared vendor account — see Section 8A and the
Documentation.
How long it is kept: Attachment files are automatically deleted from
Cloudinary approximately 3 days after upload by a daily automated cleanup
job (see Section 14). The attachment URL reference in the MASTER MEMO
sheet is replaced with a "[deleted after 3-day retention]" marker at that
point, but the row itself is not removed unless your organisation deletes
it. A legacy Drive-link file remains in the submitter's own Google Drive
under the submitter's own retention settings.
--------------------------------------------------------------------------------
3.7 Security and Audit Data (Temporary)
--------------------------------------------------------------------------------
What it is:
Email-to-memo ID mapping, token burn keys, bad attempt counters, rate limit
counters, escalation timestamps, OTP hashes, brute-force counters, and OTP
send rate limit keys.
How it is collected:
Automatically generated by the system during memo processing and Call Memo
OTP authentication.
Why it is used:
To prevent token reuse, brute force attacks, duplicate submissions, quota abuse,
OTP flooding, and to track escalation timing.
How long it is kept:
- Token burn keys: 6 hours (CacheService TTL)
- Rate limit counters: 10 minutes (CacheService TTL)
- Spam/duplicate blocks: 60 seconds (CacheService TTL)
- OTP send rate limit: 2 minutes (CacheService TTL)
- OTP brute-force counter: 10 minutes (CacheService TTL)
- OTP hash (Script Properties): 5 minutes, then auto-deleted after use
- Verified session key: 15 minutes, deleted immediately after submission
- Approver-memo mappings: auto-deleted when memo is actioned, expired, or
withdrawn
--------------------------------------------------------------------------------
3.8 OTP Authentication Data (Call Memo HTML Page)
--------------------------------------------------------------------------------
What it is:
A one-time 6-digit OTP generated when you enter your DP-01 number on the
Call Memo HTML page.
How it is collected:
Automatically generated by the system when you tap "Send Access Link" on the
Call Memo DP entry page.
Why it is used:
- To verify that you are the registered holder of the DP-01 number you entered
- To ensure that only persons whose email is registered in the TO sheet can
submit a Call Memo
- To deliver the OTP magic link to your registered email address only
- To prevent impersonation, form forwarding misuse, and unauthorised submissions
How it is stored:
The OTP is NEVER stored in plain text. It is immediately converted to a
SHA-256 cryptographic hash before storage. The raw OTP exists only in the
email sent to you. The hash is stored temporarily in Google Apps Script
PropertiesService under a key linked to your DP number. It is automatically
deleted after successful verification or after 5 minutes, whichever is sooner.
How long it is kept:
Maximum 5 minutes. Auto-deleted on successful use. Cleaned up daily by the
system's automated cleanup function.
--------------------------------------------------------------------------------
3.9 Reason for Overtime (Call Memo HTML Page)
--------------------------------------------------------------------------------
What it is:
A free-text field in the Call Memo HTML form where you enter the reason why
overtime is being called.
How it is collected:
Entered voluntarily by you at the time of Call Memo submission.
Why it is used:
- To provide justification for the overtime call in the memo record
- To inform the approver of the reason before making a decision
- To maintain an accurate record in the MASTER MEMO sheet
Input is limited to 500 characters maximum.
IMPORTANT: Do not include sensitive personal data in this field. See Section 3.5.
How long it is kept: As determined by your organisation's data retention policy.
MACHINE-READABLE DECLARATION: The above 9 categories constitute the complete
data inventory for DMS-IA v2.6. No data categories exist outside this list.
Section 8A separately discloses Licence Administration Data, which is
account-level licensing metadata rather than a category of end-user personal
data generated through the memo workflow.
================================================================================
4. DATA NOT COLLECTED — EXPLICIT EXCLUSIONS
================================================================================
DMS-IA does NOT collect, store, or process the following data under any
circumstances:
- Passwords or authentication credentials of any kind
- Mobile phone numbers or telephone numbers
- Physical home or residential address
- Date of birth or age
- Aadhaar number, PAN number, Voter ID, Passport, or any government-issued ID
- Bank account details, credit card details, salary, or any financial data
- Health or medical information of any kind
- Biometric data of any kind
- Photographs or videos, unless the user personally chooses to attach one via
the built-in Cloudinary upload or a legacy Drive link (see Section 3.6)
- Any information about your personal life outside your work identity
- Location data, GPS coordinates, or IP addresses
- Browser history or device information
- Personal Gmail account content — only the organisation's system Gmail is used
- Social media profiles or identifiers
- Racial or ethnic origin, political opinions, religious or philosophical beliefs
- Sexual orientation or gender identity
- Criminal conviction data
- Children's data (persons under 18)
- Any telemetry, crash reports, or usage analytics sent to the Developer
- Any operational data outside the deploying organisation's own Google
Workspace environment, except the limited Licence Administration Data
described in Section 8A and the attachment files described in Section 3.6
- The raw OTP code — only its SHA-256 hash is stored, never the plain OTP
- The contents of any legacy Google Drive file shared via attachment link —
only the URL is stored
================================================================================
5. DATA MINIMISATION PRINCIPLE
================================================================================
DMS-IA is built on the principle of data minimisation as required by DPDPA 2023
Section 4(1)(b), GDPR Article 5(1)(c), and Google's API User Data Policy.
- Purpose limitation: Each data element is collected for one specific purpose
only. No data is repurposed or used for profiling.
- Minimum fields: DMS-IA collects exactly 9 data categories (Section 3). The
Official Memo HTML form and Call Memo HTML page contain only the fields
strictly required for memo routing.
- Temporary security data auto-deleted: Token burn keys, rate limit counters,
and spam blocks are stored in CacheService with TTLs of 60 seconds to 10
minutes and are never persisted beyond their TTL.
- OTP hash storage: The raw OTP is never stored. Only its SHA-256 hash is
stored in Script Properties for a maximum of 5 minutes.
- DP-number-only URL transmission: When submitting a Call Memo with people
selected, only DP numbers are sent in the URL. Full names and designations
are reconstructed server-side from WORKER LIST. This eliminates URL
truncation risk and minimises data in transit.
- 30-person limit enforced server-side: Call Memo submissions are capped at
a maximum of 30 workers per memo. This limit is enforced both client-side
(checkbox disabling) and server-side (hard rejection). This deliberately
limits the volume of personal data per memo record.
- Email pre-filled server-side: The Call Memo HTML page retrieves your email
from the TO sheet and pre-fills it as read-only. You never type or transmit
your email manually, reducing input error and data exposure risk.
- Approval mapping auto-deleted: The approver email stored in Script Properties
(a_+memoId) is automatically deleted the instant the memo is actioned, expired,
or withdrawn.
- Input length limits enforced: Subject capped at 200 characters. Context /
Message capped at 3,000 characters. Reason for OT capped at 500 characters.
- Attachment size and retention limits: File attachments (a configured number
of photographs, one video, one other document) are capped at 10MB per image
and 100MB for video, and are automatically deleted from Cloudinary after a
3-day retention period — DMS-IA does not retain attachment files
long-term. Legacy Drive links remain accepted as URL-only references,
where DMS-IA does not fetch, read, or store the file content.
- No developer data collection beyond licence administration: The Developer
architecture contains no telemetry endpoint, no analytics hook, and no
mechanism to receive memo or HR data. The only data the Developer receives
is the limited Licence Administration Data described in Section 8A.
================================================================================
6. PURPOSES OF PROCESSING
================================================================================
6.1 Core Memo Workflow
Your email address and DP number are used to route your submitted memo to the
correct approver and to send you status notifications.
6.2 Identity Verification via HMAC-SHA256
Your email address is cryptographically encoded into each approval link using
HMAC-SHA256. When you click the link, the system recomputes the hash and verifies
it matches. This ensures only the intended approver can action a memo. You should
not share approval links with any other person as they contain your encoded
identity information.
6.3 Approval Link Security — Script Properties
When an approval or rejection link is generated for you, your email address is
stored in Google Apps Script PropertiesService linked to the memo ID
(key: "a_" + memoId). This is used exclusively to verify your identity when you
click the link. This data is stored within your organisation's Google Apps Script
environment, is never accessible to the Developer, and is automatically deleted
the instant the memo is actioned, expired, or withdrawn.
6.4 Escalation Routing
Your department name is used to identify and contact the correct department
authority if a memo is not actioned within the configured time limit (default:
24 hours for Stage 1, 48 hours for Stage 2). Escalation emails are
information-only — no action buttons are provided.
[SECTION 6.5 REMOVED IN v2.5]
Gmail Sent Folder Access has been removed from DMS-IA. GmailApp.search() is
no longer used. The LINK 1 and LINK 2 columns in MASTER MEMO now store the
plain text label "SENT" to confirm email delivery, replacing the previous Gmail
thread URL. No Gmail inbox, sent folder, or email content is read by DMS-IA.
6.5 Audit Trail
Your email address, name, and the action you took are recorded in a permanent
audit log for organisational accountability and traceability.
6.6 PDF Documentation
Your name is displayed in the memo PDF document in the Authorization section
to identify who submitted and who approved or rejected the memo.
6.7 Backup
Your data may be included in automated weekly backups of the memo records,
retained for a maximum of 4 weeks and then automatically deleted.
6.8 Security Event Recording
If an approval or rejection link associated with your memo is used incorrectly
or appears to be tampered with, DMS-IA records the failed attempt. If the maximum
number of failed attempts is reached (default: 5), the memo is automatically
locked and your organisation's administrator is notified.
6.9 Administrative Reporting
A daily summary email to the administrator contains aggregate statistics only —
pending count, approved count, rejected count, and email quota remaining. No
individual personal data is included beyond what the administrator already has
direct access to.
6.10 Delegated Approval
If your organisation has configured the delegation feature and the primary
approver does not act within the set time limit, your memo content including
your name and department may be automatically forwarded to a backup approver
designated by your organisation.
6.11 OTP Authentication for Call Memo
When you use the Call Memo HTML page (accessed via QR code), the system:
(1) Accepts your DP-01 number as input
(2) Looks up your registered email address from the TO sheet
(3) Generates a one-time 6-digit OTP, hashes it with SHA-256, and stores the
hash in Script Properties for a maximum of 5 minutes
(4) Sends a magic link email to your registered address only
(5) When you click the link, verifies the OTP hash against the stored value
(6) On successful verification, deletes the OTP hash, opens the Call Memo form
with your email pre-filled and read-only
Your email is never shown to you during entry — only a masked version
(e.g. ro***@company.com) is displayed for confirmation. This prevents
impersonation and ensures only registered employees can submit Call Memos.
6.12 Call Memo Submission
When you submit a Call Memo via the HTML page, your email address is verified
against the TO sheet on the server before the memo is written to the CALL MEMO
sheet. Only DP numbers of selected workers are transmitted in the URL — names
and designations are reconstructed server-side from the WORKER LIST sheet to
prevent data loss from URL length limits. The Reason for Overtime you enter is
stored in the memo context alongside the people list.
Upon successful submission, a confirmation email is automatically sent to your
registered email address containing your Memo ID, department, call time, subject,
and count of people selected. This email serves as your receipt and proof of
submission. It does not contain the full names of selected workers — only the
count.
6.13 CC DP-01 Live Validation (Official Memo)
When a submitter enters a CC DP-01 number on the Official Memo HTML form, the
system performs a live lookup (via the CHECKDP action) to verify whether the
DP-01 is registered in the system. If valid, the registered name and department
are displayed as confirmation. If invalid, submission is blocked. No additional
personal data is collected — only the DP-01 entered by the submitter is used
for this lookup.
================================================================================
7. USER CONSENT AND LAWFUL BASIS FOR DATA COLLECTION
================================================================================
DMS-IA operates within an organisational context. The lawful basis for processing
personal data is as follows for each user category:
Memo Submitters (Official Memo HTML Form):
Basis: Implied consent + contractual necessity
How: By voluntarily submitting a memo via the Official Memo HTML web form, the
submitter knowingly provides their data for the stated purpose in the course of
their employment within the organisation.
Call Memo Submitters (HTML Page):
Basis: Implied consent + contractual necessity
How: By entering their DP-01 number and requesting an OTP link, the submitter
voluntarily initiates the authentication process. By clicking the magic link
and submitting the form, they knowingly provide their data for the stated
purpose. The email pre-fill is a system convenience from registered data, not
new collection.
Approvers:
Basis: Legitimate interest + employment contract
How: Approver details are entered by the administrator as part of system setup.
Approvers act in their official capacity as employees performing their role.
CC Recipients:
Basis: Legitimate interest
How: CC is an optional field. If used, the CC recipient is an employee of the
organisation receiving information relevant to their work. The CC DP-01 is
verified live before submission to ensure validity.
Administrators:
Basis: Contractual + legitimate interest
How: Administrators configure the system and receive alert emails in their
official capacity as the system operator.
HODs / Managers:
Basis: Legitimate interest
How: Escalation emails are sent to department authorities in their official
capacity when a memo within their department is unactioned past the threshold.
The deploying organisation is responsible for informing their employees about
DMS-IA's data processing as part of their own employee privacy notices or
acceptable use policies. This Policy should be made available to all users.
================================================================================
8. GOOGLE API SERVICES — LIMITED USE DISCLOSURE
================================================================================
DMS-IA's use of Google API data adheres strictly to the Google API Services
User Data Policy including the Limited Use requirements.
Mail API (MailApp — script.send_mail scope):
Data Accessed : Send-only. DMS-IA sends approval request emails, rejection
notifications, escalation alerts, OTP magic link emails,
delegation notifications, and administrative health reports.
DMS-IA does NOT read, search, or access any Gmail inbox,
sent folder, drafts, or email thread. GmailApp is not used.
Purpose : Send all outbound emails required by the DMS-IA workflow.
All emails include the deploying organisation's name as the
sender display name.
Limited Use : YES — send only. No Gmail read access whatsoever.
Scope : https://www.googleapis.com/auth/script.send_mail (non-restricted)
Google Sheets API (SpreadsheetApp — spreadsheets scope):
Data Accessed : Read/write to the spreadsheet in which DMS-IA is installed only.
Reads WORKER LIST sheet to reconstruct worker names from DP
numbers server-side. Reads TO/FROM sheets to look up registered
emails and DP numbers. Writes to MASTER MEMO, QUEUE, CALL MEMO,
AUDIT LOG, BACKUP, COMMAND CENTER, and QR CODE sheets.
Purpose : Store memo data, config, audit log, backups, dashboard, and
Call Memo data. Look up worker and approver details.
Limited Use : YES — own spreadsheet only. No access to other spreadsheets.
Scope : https://www.googleapis.com/auth/spreadsheets (non-restricted)
Apps Script Triggers (ScriptApp — script.scriptapp scope):
Data Accessed : Installs and manages time-based triggers only.
Purpose : Schedule processQueue (every 1 min), checkEscalations (every
30 min), retryFailedEmails (every 30 min), dailyHealthCheck
(daily), cleanupExpiredOtpKeys (daily), and
cleanupOldAttachments (daily, deletes expired Cloudinary
attachments) to run automatically without requiring the
owner to be present.
Limited Use : YES — trigger management only. No user data accessed via this
scope.
Scope : https://www.googleapis.com/auth/script.scriptapp (non-restricted)
External Request (UrlFetchApp — script.external_request scope):
Data Accessed : Three external targets only:
(1) drive.google.com CDN — to download publicly-shared legacy
Drive file attachments (if a Drive link is provided with a
memo) for inclusion in approval emails. No OAuth token is
sent. Only files with "Anyone with the link" sharing are
fetched.
(2) api.qrserver.com — to generate a QR code image from the
deployment URL. Only the /exec Web App URL is transmitted.
No personal data is sent to this service.
(3) api.cloudinary.com (Cloudinary Admin API) — to delete
expired memo attachments after the 3-day retention period
(see Sections 3.6 and 14). Authenticated with the
Cloudinary API key and secret; only the attachment's
Cloudinary public ID is transmitted, no other personal
data.
Purpose : Fetch legacy attachments for email inclusion; generate QR
code; delete expired Cloudinary attachments.
Note : The initial upload of a new attachment to Cloudinary happens
directly from the Authorised User's browser via Cloudinary's
own upload API, and does not use this scope or any Google
server — see Section 3.6.
Limited Use : YES — three specific external services only, none of which
receive personal memo/HR data beyond what is described above.
Scope : https://www.googleapis.com/auth/script.external_request
(non-restricted)
Apps Script Container UI (SpreadsheetApp.getUi — script.container.ui scope):
Data Accessed : No user data accessed.
Purpose : Create the ⚙ DMS-IA custom menu in the spreadsheet toolbar,
and display alert/confirmation dialogs during setup and settings
sync operations.
Limited Use : YES — UI only. No data read or written via this scope.
Scope : https://www.googleapis.com/auth/script.container.ui
(non-restricted)
User Info (Session.getActiveUser — userinfo.email scope):
Data Accessed : Email address of the Google account running selfSetup().
Purpose : Auto-detect and store the ADMIN_EMAIL during initial system
setup. Not used during normal operation.
Limited Use : YES — setup only. Not stored beyond setup completion.
Scope : https://www.googleapis.com/auth/userinfo.email (non-restricted)
Apps Script Properties (PropertiesService — no separate scope):
Data Accessed : Key-value: approver emails per memo, counters, config values.
Also stores OTP SHA-256 hashes (max 5 min TTL) and verified
session keys (max 15 min TTL) for Call Memo auth.
Purpose : Store operational config and temporary security data.
Limited Use : YES — own script only. Encrypted at rest by Google.
Apps Script Cache (CacheService — no separate scope):
Data Accessed : Burn keys, rate counters, spam blocks, duplicate blocks.
Also stores OTP send rate limit keys (2 min TTL) and OTP
brute-force attempt counters (10 min TTL). All auto-expire.
Purpose : Security — prevent token reuse, brute force, spam, OTP flooding.
Limited Use : YES — auto-expires. Never persistent.
HtmlService (no separate scope):
Data Accessed : Serves HTML pages to the user's browser.
Purpose : Render the Official Memo HTML form (including live DP-01
name lookup, CC validation, priority chips, attachment
uploader, preview panel, and three-step submission flow),
approval/rejection pages, rejection comment form, memo print
view, Call Memo QR landing page, OTP DP entry page, "check
your email" waiting page, and Call Memo submission form.
Limited Use : YES — no user data collected from HTML pages beyond what
the user explicitly enters and submits. No cookies, no tracking,
no external scripts other than the Cloudinary upload API call
described in Section 3.6. CSP compliant — no inline event
handlers.
--- GOOGLE LIMITED USE COMPLIANCE DECLARATION ---
DMS-IA's use of Google API data is limited to:
(1) Providing the DMS-IA memo workflow service;
(2) Uses described in this Privacy Policy;
(3) Uses permitted by the deploying organisation's Google Workspace administrator.
DMS-IA does NOT:
- Transfer data to third parties for advertising
- Use data for purposes unrelated to memo management
- Sell or rent Google user data
- Use data to train AI or machine learning models
- Allow any human including the Developer to read user data
- Read Gmail inbox, sent folder, or any email thread (GmailApp not used)
- Upload files to any external server other than Cloudinary, and only where
an Authorised User has voluntarily chosen to attach a file (see Section 3.6)
================================================================================
8A. LICENCE ADMINISTRATION DATA — DEVELOPER'S LIMITED DATA COLLECTION
================================================================================
This Section discloses, in full, the only personal data the Developer receives
from any DMS-IA deployment. It is separate from, and far more limited than, the
operational memo/HR data described in Sections 3 and 6, which the Developer
never accesses.
8A.1 What Is Collected
At the time of initial setup (selfSetup()), and only at that time, the
Software transmits the following to the Developer:
(a) The organisation/company name entered during setup;
(b) The administrator's email address (ADMIN_EMAIL);
(c) The unique identifier of the Google Spreadsheet in which DMS-IA is
installed.
8A.2 How It Is Collected and Where It Is Stored
This data is written, using a dedicated Developer-controlled service account,
directly into a Google Sheet maintained solely by the Developer (the "Licence
Register"), and is also sent once, by automated email, to
admin@yourdigiemployee.com — the Developer's dedicated licence and renewal
contact address (also used, separately, for the trial-ending and
licence-expired messages the Software shows directly to your organisation's
administrator; see Section 23). Duplicate registrations (e.g. re-running
selfSetup() on an already-registered deployment) are detected and skipped —
no repeat write or email occurs.
8A.3 Why It Is Collected
This data exists solely to allow the Developer to:
(a) Track which deployments are active, on trial, or on a paid licence;
(b) Calculate and enforce trial and licence expiry dates;
(c) Send licence activation and renewal correspondence to the correct
administrator;
(d) Provide support in connection with a specific deployment, if requested.
8A.4 Ongoing Licence Status Checks
After initial setup, the Software periodically checks (no more than once
every 6 hours, using a local cache) whether the deployment's licence is
still valid. This check uses only the deployment's spreadsheet identifier as
a lookup key against the Licence Register, via the same Developer-controlled
service account. No memo content, HR data, attachment, or any other
operational data is transmitted as part of this check.
8A.5 Retention
Licence Administration Data is retained in the Licence Register for as long
as is reasonably necessary for licence administration, billing, and support
record-keeping, and in any event no longer than is required by applicable
law (including for tax and accounting purposes under Indian law).
8A.6 No Further Use or Sharing
Licence Administration Data is used solely for the purposes in Section 8A.3
and is not used for marketing, profiling, advertising, or any purpose beyond
licence administration and support. It is not sold, rented, or shared with
any third party, except a service provider strictly necessary to operate the
Licence Register itself (i.e. Google, as the underlying platform on which the
Licence Register is hosted).
8A.7 Your Rights
An administrator may request access to, correction of, or deletion of their
organisation's Licence Administration Data by contacting
romit232091@gmail.com. Deletion of Licence Administration Data tied to an
active, paid licence may affect the Developer's ability to verify continued
entitlement to use the Software.
================================================================================
9. SUB-PROCESSORS AND THIRD-PARTY SERVICE PROVIDERS
================================================================================
The following is the COMPLETE and exhaustive list of all sub-processors used
by DMS-IA. No other parties exist beyond this list.
Sub-Processor : Google LLC
Country : USA (Global infrastructure)
Service : Google Sheets, Gmail (send only), Google Apps Script —
the entire platform on which DMS-IA runs
Data Involved : All personal data processed by DMS-IA, plus the Licence
Register (Section 8A), which is also hosted on Google's
infrastructure
Safeguards : Google Workspace Terms, Data Processing Addendum, Privacy
Policy (policies.google.com)
Sub-Processor : Cloudinary
Country : USA (headquarters); infrastructure hosted primarily on AWS,
with data centres located globally, primarily in the USA
Service : Storage and delivery of file attachments (photographs,
videos, and documents) voluntarily uploaded by Authorised
Users through the Official Memo Module
Data Involved : The content of any file an Authorised User chooses to
attach to a memo. By default this is stored under a single
shared Developer-owned Cloudinary account used by every
DMS-IA deployment, with each deployment's files kept under
its own distinct, non-reversible folder within that shared
account (see Safeguards below); an organisation may instead
configure its own Cloudinary account (see Section 8A and
the Documentation) so its attachments are stored under an
account it controls instead of the shared vendor account.
Retention : Automatically deleted from Cloudinary approximately 3 days
after upload by a daily automated cleanup job (Section 14).
Safeguards : Files are uploaded directly from the Authorised User's
browser to Cloudinary using an unsigned upload preset
(Cloudinary's standard mechanism for safe direct
client-side uploads, with no secret credential exposed to
the browser); deletion is authenticated via Cloudinary's
Admin API using credentials the Developer controls. Every
deployment's attachments are namespaced under a distinct
folder (derived from a one-way hash of that deployment's
spreadsheet ID) within the shared account, so files from
different organisations are not stored in a single flat,
undifferentiated namespace; this is a defense-in-depth
measure and not a substitute for the full isolation of a
dedicated Cloudinary account. Cloudinary's own Data
Processing Agreement and the EU Standard Contractual
Clauses / EU-US, UK-US, and Swiss-US
Data Privacy Framework govern cross-border transfers — see
cloudinary.com/trust.
Sub-Processor : GoQR.me / api.qrserver.com
Country : Germany (Servers)
Service : QR code image generation
Data Involved : ONLY the deployment Web App URL (/exec URL). No personal
data whatsoever is sent to this service. The URL is a
publicly visible Apps Script deployment URL.
Safeguards : HTTPS transport only. No authentication, no account, no
persistent data storage on their end.
Purpose : Generate the QR code image displayed on the QR CODE sheet
for worker access to the Call Memo form.
No other sub-processors:
DMS-IA integrates with no other external service, API, or platform beyond
the three listed above. No CDN beyond Cloudinary, no analytics SDK, no
advertising network, and no other external API is ever called by DMS-IA.
================================================================================
10. DATA STORAGE — LOCATION AND ACCESS CONTROL
================================================================================
ALL memo, HR, and operational personal data is stored exclusively within the
deploying organisation's own Google Workspace account. The Developer holds no
infrastructure that stores or has access to this data. This is subject to the
two limited, fully-disclosed exceptions described below (Cloudinary attachment
storage and the Developer's Licence Register).
Google Sheets (Organisation's Drive):
Data : MASTER MEMO, QUEUE, RETRY QUEUE, FROM/TO, DEPARTMENTS, SETTINGS,
AUDIT LOG, BACKUP, WORKER LIST sheets
CALL MEMO sheet — stores all Call Memo submissions including
submitter email, DP-01, department, call time, subject, reason
for OT, and reconstructed people list. Permanent record.
QR CODE sheet — stores the QR code image linking to the Call
Memo web app URL. Contains no personal data — only the deployment
URL encoded as a QR image for printing and display.
Note: Official Memo submissions are received via the HTML web form
(not Google Form). All submissions flow through the QUEUE sheet
before being written to MASTER MEMO.
Access : Sheet protection removes all editors including the owner for
protected sheets. Script execution bypasses protection by GAS
design. No manual browser editing possible by any user on
protected sheets.
Developer Access: NONE
Script Properties (PropertiesService):
Data : WEB_APP_URL, ADMIN_EMAIL, HMAC_SECRET, approver-memo mappings,
bad attempt counters, escalation timestamps, backup week keys,
OTP SHA-256 hashes (max 5 min), verified session keys (max 15 min)
Access : Encrypted at rest by Google. Script-scope only. Never accessible
to the Developer.
Developer Access: NONE
CacheService:
Data : Token burn keys, rate limit counters, spam blocks, duplicate blocks,
OTP send rate limit keys (2 min TTL), OTP brute-force counters
(10 min TTL). All auto-expire within stated TTLs.
Access : Script-scope only. No persistence beyond TTL.
Developer Access: NONE
Google Drive (Submitter's account — legacy attachment links only):
Data : Where a legacy Drive link is used, the file remains in the
submitter's own Google Drive. DMS-IA stores only the publicly
shared URL, not the file itself.
Access : Submitter's own Google Drive permissions apply.
Developer Access: NONE
Cloudinary (Shared Developer-owned account by default):
Data : The content of file attachments (photographs, videos, documents)
uploaded through the Official Memo Module's built-in uploader —
see Section 3.6 and Section 9.
Access : Files are uploaded directly by the Authorised User's browser; the
Developer does not manually view attachment content in the
ordinary course. The Developer's account credentials are used
only to authenticate the automated 3-day retention deletion job
(Section 14) via Cloudinary's Admin API. An organisation may
configure its own Cloudinary account to remove its attachments
from the shared vendor account entirely.
Developer Access: ADMINISTRATIVE ONLY — automated deletion after the
retention period. No routine manual access to file content.
Developer's Licence Register (Google Sheet, Developer-owned):
Data : Deployment spreadsheet ID, organisation name, administrator email
address, licence tier, and licence expiry date — see Section 8A
for full disclosure. Does NOT include any memo, HR, or attachment
data.
Access : Developer only, via a dedicated service account.
Developer Access: YES — limited strictly to the licence administration
data described in Section 8A.
Developer Infrastructure Summary: The Developer operates no infrastructure
that stores or has access to your organisation's memo, HR, or operational
data. The only Developer-controlled data stores are the Licence Register
(licence administration metadata only, Section 8A) and the shared
Cloudinary account (attachment files, until automatically deleted, unless
your organisation uses its own Cloudinary account instead).
================================================================================
11. DATA SHARING — COMPLETE STATEMENT
================================================================================
The following is the COMPLETE statement of all data sharing in DMS-IA.
No data sharing exists beyond what is described here.
Within the Organisation (Necessary):
Your name, department, and memo content are visible to the designated approver,
the CC recipient if configured, and your department HOD/manager in escalation
emails (information only). This is the core intended function and is always
with your knowledge and intent when submitting a memo.
Call Memo People List:
When you are selected by a Call Memo submitter as a person involved, your name,
DP number, and designation from the WORKER LIST sheet appear in the Call Memo
record and in the notification email sent to the approver. This is consistent
with your employment role and is visible only within the organisation.
Automatic Delegation:
If configured, your memo may be forwarded to a backup approver if the primary
does not act within the set time limit.
With Google (Infrastructure):
Data is processed on Google's servers under Google's Privacy Policy and
Workspace Terms.
With Cloudinary (Attachment Storage):
By default, the content of any file an Authorised User voluntarily attaches to
a memo is transmitted to and temporarily stored on a Developer-administered
Cloudinary account, until automatically deleted after 3 days. See Sections
3.6, 9, and 10. An organisation may eliminate this by configuring its own
Cloudinary account.
With api.qrserver.com (Limited):
ONLY the deployment URL is transmitted — no personal data.
With the Developer — Limited to Licence Administration and Attachment
Storage:
The Developer does not receive, access, view, copy, analyse, or process any
memo, HR, or operational personal data from any deployment. The Developer
does receive limited Licence Administration Data (organisation name,
administrator email, spreadsheet ID) at initial setup, for the purposes and
under the safeguards described in Section 8A. Additionally, by default,
attachment files uploaded through the Official Memo Module pass through and
are temporarily stored on the Developer-administered Cloudinary account
described above — the Developer does not manually view this content in the
ordinary course.
With Third Parties — Cloudinary and api.qrserver.com Only:
Beyond Google's infrastructure, the only other data transmitted is: (a) the
content of voluntarily-uploaded attachment files, to Cloudinary, by default
under the shared vendor account; and (b) the deployment URL only, to
api.qrserver.com, for QR code generation. No other personal data is
transmitted to any other third party.
Sale of Data — NEVER:
Personal data is never sold, rented, traded, or monetised in any form.
================================================================================
12. SECURITY MEASURES
================================================================================
DMS-IA implements the following security measures to protect your personal data:
Cryptographic Token Security (HMAC-SHA256):
Every approval and rejection link is signed with HMAC-SHA256 cryptography and
is mathematically bound to your specific email address, memo ID, decision type,
and timestamp.
Single-Use Burn Keys:
Each approval or rejection link can only be used once.
Time-Limited Links:
Approval links expire after 48 hours by default.
Brute Force Lockout:
After a configurable number of failed token attempts (default: 5), the memo is
automatically locked and the administrator is immediately alerted.
OTP SHA-256 Hash Storage:
The raw 6-digit OTP is never stored. Immediately upon generation, it is hashed
using SHA-256 and only the hash is stored in Script Properties. Even if Script
Properties were somehow accessed, the raw OTP could not be recovered.
OTP Single-Use:
Each OTP magic link can be used exactly once. After successful verification, the
OTP hash is immediately deleted from Script Properties.
OTP Expiry:
OTP magic links expire after 5 minutes. Expired links are permanently invalid.
OTP Brute-Force Protection:
A maximum of 5 OTP verification attempts are permitted per DP number per 10
minutes. After 5 failed attempts, further attempts are blocked for 10 minutes.
OTP Send Rate Limiting:
A maximum of 1 OTP magic link can be sent per DP number per 2 minutes. This
prevents OTP flooding attacks against any registered employee's email inbox.
Email Pre-Fill Security (Call Memo):
The email address shown on the Call Memo form is retrieved server-side from
the TO sheet and rendered read-only. It cannot be modified by the user in the
browser. Server-side validation re-verifies the email against the TO sheet
at submission time, so even if the HTML is modified client-side, the check
still passes only for registered emails.
DP-Number-Only URL Transmission:
Only DP numbers are sent in the submission URL — not names or designations.
Names are reconstructed server-side from WORKER LIST. This eliminates the risk
of URL truncation causing data loss for large people lists.
CC DP-01 Live Validation:
On the Official Memo HTML form, the CC DP-01 field is validated live against
the registered DP list (CHECKDP action). If the DP is invalid, submission is
blocked with an error message. Blank CC is permitted (CC is optional).
Attachment Upload Security (Cloudinary):
Attachment uploads use an unsigned Cloudinary upload preset, which is
Cloudinary's designed mechanism for safe direct browser uploads — it allows
uploads without exposing the account's API secret to the browser. The API
key and secret are used only server-side, for the automated deletion job.
Attachments are automatically deleted after a 3-day retention period. Where
the shared vendor Cloudinary account is used, every deployment's
attachments are additionally namespaced under a distinct, non-reversible
per-deployment folder (derived from a one-way hash of that deployment's
spreadsheet ID), so that one organisation's files are not stored in the
same flat namespace as another's — see Section 9.
CSP-Compliant HTML Pages:
All HTML pages served by DMS-IA (Official Memo form, Call Memo form, approval
pages, rejection form, print view, OTP pages) do not use inline event handlers
(onclick=, onchange=, onload=, etc.). All interactivity is wired via JavaScript
addEventListener calls, making the pages Content Security Policy compliant.
Rate Limiting, Full Sheet Protection, Clickjacking Prevention, Email Case
Normalisation, HMAC Secret Enforcement, Tamper-Evident Audit Log, HTTPS
Transport, and Self-Healing Architecture remain as documented in v2.1.
================================================================================
13. DATA BREACH AND INCIDENT RESPONSE PROCEDURE
================================================================================
A "data breach" means any unauthorised access to, disclosure of, or destruction
of personal data stored in an organisation's DMS-IA deployment, in the
Developer's Licence Register, or in the shared Cloudinary account.
13.1 Who Is Responsible:
Since all memo/HR data is stored within the deploying organisation's own Google
Workspace account, the deploying organisation (as Data Controller) bears
primary responsibility for breach detection, assessment, containment, and
notification under DPDPA 2023 Section 8(6) and GDPR Article 33, in respect of
that data. The Developer bears equivalent responsibility for any breach of the
Licence Register or the shared Cloudinary account.
13.2 Developer's Breach Obligations:
If the Developer becomes aware of a vulnerability in DMS-IA code, in the
Licence Register, or in the shared Cloudinary account, that could lead to a
breach, the Developer will:
(1) Notify affected licensees within 72 hours of discovery;
(2) Publish a patched version of DMS-IA, or take equivalent remedial action
for the Licence Register or Cloudinary account, as applicable;
(3) Provide remediation guidance.
Contact: romit232091@gmail.com
13.3 Deploying Organisation's Obligations:
Under DPDPA 2023 and GDPR, the deploying organisation must:
(1) Notify the Data Protection Board of India within 72 hours (DPDPA S.8(6));
(2) Notify affected data principals without undue delay if harm is likely;
(3) Document all breaches in their breach register.
================================================================================
14. DATA RETENTION SCHEDULE
================================================================================
DMS-IA stores your personal data for as long as your organisation requires.
Retention schedule by data type:
Memo records (MASTER MEMO, CALL MEMO):
Retention : Organisation decides
Deletion : Admin manually deletes rows or sheet
Queue rows (DONE/FAILED/WITHDRAWN):
Retention : Auto-deleted after 7 days
Deletion : cleanupOldQueueRows() — runs daily automatically
Attachment files (Cloudinary):
Retention : Approximately 3 days from upload
Deletion : cleanupOldAttachments() — runs daily automatically, deletes the
file from Cloudinary via the Admin API and replaces the MASTER
MEMO attachment reference with a "[deleted after 3-day
retention]" marker. Legacy Drive-link attachments are not
affected by this job — they remain under the submitter's own
Google Drive retention settings.
OTP hash (Script Properties):
Retention : Maximum 5 minutes
Deletion : Auto-deleted on successful verification. Additionally, the system
runs cleanupExpiredOtpKeys() automatically every day via a scheduled
trigger. This function scans all Script Properties keys prefixed
with OTP_ or VFD_ and deletes any that have passed their expiry
timestamp, preventing quota accumulation over time.
Verified session key (Script Properties):
Retention : Maximum 15 minutes
Deletion : Auto-deleted on form submission, or by daily cleanup
OTP send rate limit key (CacheService):
Retention : 2 minutes
Deletion : Auto-expires via CacheService TTL
OTP brute-force counter (CacheService):
Retention : 10 minutes
Deletion : Auto-expires via CacheService TTL; cleared on successful OTP
Audit log entries:
Retention : Indefinite — permanent record
Deletion : Admin manually (not recommended)
Weekly backup sheets:
Retention : Last 4 Sundays only
Deletion : Oldest auto-deleted when 5th backup is created
Token burn keys:
Retention : Maximum 6 hours
Deletion : Auto-expires via CacheService TTL
Approver-memo mappings:
Retention : Until memo is actioned, expired, or withdrawn
Deletion : Automatically deleted by processApproval() or recallMemo()
Licence Administration Data (Developer's Licence Register):
Retention : For as long as reasonably necessary for licence administration,
billing, and support record-keeping (Section 8A.5)
Deletion : On request to romit232091@gmail.com, subject to Section 8A.7
Rate limit counters: 10 minutes | Spam/duplicate blocks: 60 seconds
================================================================================
15. YOUR RIGHTS
================================================================================
You have the following rights: Right to Information, Right to Access, Right to
Correction, Right to Erasure, Right to Withdraw Memo, Right to Restrict
Processing, Right to Data Portability, Right to Object, Right Against Automated
Decision-Making, Right to Grievance Redressal (romit232091@gmail.com, 7 business
days), and CCPA rights for California residents.
Most rights are exercised through your organisation's administrator. Rights
concerning Licence Administration Data specifically (Section 8A) may be
exercised directly with the Developer at romit232091@gmail.com.
For consent withdrawal, follow the four-step procedure in Section 27.
================================================================================
16. LEGAL BASIS FOR PROCESSING
================================================================================
Core Memo Workflow:
DPDPA 2023 : Legitimate purpose — internal operational communication
GDPR : Art.6(1)(b) — performance of employment contract
Parties : All submitters and approvers
Escalation Routing:
DPDPA 2023 : Legitimate purpose — organisational oversight
GDPR : Art.6(1)(f) — legitimate interest
Parties : Department heads, managers
Email Notifications (MailApp):
DPDPA 2023 : Legitimate purpose — status communication
GDPR : Art.6(1)(b) — performance of employment contract
Parties : Submitters, approvers, CC recipients
Note : Sent via MailApp only (script.send_mail scope). GmailApp not used.
Call Memo OTP Authentication:
DPDPA 2023 : Legitimate purpose — identity verification and security
GDPR : Art.6(1)(f) — legitimate interest
Parties : Call Memo submitters
Call Memo Submission:
DPDPA 2023 : Legitimate purpose — internal operational communication
GDPR : Art.6(1)(b) — performance of employment contract
Parties : Call Memo submitters and selected workers
CC DP-01 Validation:
DPDPA 2023 : Legitimate purpose — data accuracy and routing
GDPR : Art.6(1)(f) — legitimate interest
Parties : CC recipients
Attachment Upload (Cloudinary):
DPDPA 2023 : Legitimate purpose — supporting documentation for the memo
GDPR : Art.6(1)(b) — performance of employment contract; Art.6(1)(a)
— consent, given voluntarily by choosing to attach a file
Parties : Submitters who choose to attach a file
Licence Administration Data:
DPDPA 2023 : Legitimate purpose — contract performance and billing
GDPR : Art.6(1)(b) — performance of the licence contract
Parties : The Licensee's administrator (Section 8A)
Audit Log:
DPDPA 2023 : Legitimate purpose — accountability and traceability
GDPR : Art.6(1)(f) — legitimate interest
Parties : All users
Security Processing (HMAC, burn keys, rate limits, OTP hashes):
DPDPA 2023 : Legitimate purpose — security and fraud prevention
GDPR : Art.6(1)(f) — legitimate interest
Parties : All users
================================================================================
17. COOKIES, TRACKING, AND ANALYTICS
================================================================================
DMS-IA does not use cookies, tracking pixels, web beacons, session tokens,
fingerprinting, analytics SDKs, advertising scripts, or any other form of
tracking technology.
All HTML pages served by DMS-IA — the Official Memo form, Call Memo HTML pages
(DP entry, OTP waiting, submission form), approval/rejection pages, rejection
comment form, and memo print view — are served by Google Apps Script HtmlService.
They do not set cookies, do not call any analytics endpoint, and do not collect
any device or browser information beyond what the user explicitly enters and
submits. The only external script call made from these pages is the direct
browser-to-Cloudinary upload request described in Section 3.6, which is not a
tracking or analytics call. All pages are CSP compliant with no inline event
handlers.
Any cookies set when accessing DMS-IA pages are set by Google's infrastructure
and are governed by Google's Cookie Policy, not by DMS-IA.
================================================================================
18–21. INTERNATIONAL TRANSFERS, CHILDREN'S PRIVACY, GOOGLE PLATFORM,
TERMS OF SERVICE
================================================================================
[Unchanged from v2.1 — all provisions remain in full effect, subject to the
Cloudinary cross-border disclosure added at Section 26.4]
================================================================================
22. CHANGES TO THIS PRIVACY POLICY
================================================================================
The Developer may update this Privacy Policy from time to time. The Last Updated
date at the top of this document will be revised for all updates.
This version (2.6, 19 July 2026) updates the policy to reflect the introduction
of direct browser-to-Cloudinary attachment uploads as the primary attachment
method (with legacy Drive links still supported), the resulting Cloudinary
sub-processor disclosure, and the addition of Section 8A disclosing the
limited Licence Administration Data (organisation name, administrator email,
spreadsheet ID) transmitted to the Developer at initial setup for licence
tracking and renewal billing. Version 2.5 (29 June 2026) reflected the removal
of GmailApp and the Gmail Sent folder search, the replacement of Google Form
with the Official Memo HTML web form, the removal of DriveApp and FormApp, the
addition of api.qrserver.com as a limited sub-processor, the introduction of
CC DP-01 live validation, the mandatory Context / Message field, and
CSP-compliant HTML across all served pages.
================================================================================
23. CONTACT AND GRIEVANCE OFFICER
================================================================================
Name : Rohmit Neelakant Shirgoppi
Aadhaar Name : Neelkant Shirgoppi
Role : Developer, Owner, and Grievance Officer — DMS-IA
Email : romit232091@gmail.com (privacy grievances and general contact)
admin@yourdigiemployee.com (licence, trial, and renewal
matters — this is the address the Software itself displays
in its trial-ending and licence-expired messages, and the
address the Licence Administration Data described in
Section 8A is emailed to)
Phone : +91-9535835504
Address : H.No. 522, Near CSI Church, Teachers Colony Road,
Township, Dandeli — 581325, Karnataka, India
Both addresses are monitored by the same person (the Developer). Use
romit232091@gmail.com for privacy grievances under this Section; either
address reaches the Developer for licence or support matters.
BINDING RESPONSE COMMITMENT:
The Developer commits to acknowledging all written grievances within
7 business days of receipt at romit232091@gmail.com. This is a binding
commitment. If the Developer fails to acknowledge within 7 business days,
the complainant may escalate directly to the Data Protection Board of India
(meity.gov.in) or the relevant regulatory authority without any further
obligation to await a response. The 7-business-day period begins on the
first business day following receipt of the written grievance.
For the purpose of this Section, "business days" means Monday to Friday
excluding public holidays in Karnataka, India.
How to submit a grievance:
(1) Send a written email to romit232091@gmail.com with subject line:
"DMS-IA Privacy Grievance — [Your Name] — [Date]"
(2) Describe the specific data processing activity you are concerned about
(3) State the right you wish to exercise or the remedy you seek
(4) Include your contact details for the response
The Developer will provide a substantive response within 30 calendar days
of acknowledgement. If the matter cannot be resolved within 30 days, the
Developer will inform you of the reason and the expected resolution timeline.
Regulatory Authorities:
India (DPDPA 2023) : Data Protection Board of India — meity.gov.in
India (IT Act 2000): Ministry of Electronics and IT — meity.gov.in
European Union : Your national DPA — edpb.europa.eu
California (CCPA) : California Privacy Protection Agency — cppa.ca.gov
Google Platform : Google Privacy Team — policies.google.com/privacy
================================================================================
25. DATA PROTECTION OFFICER (DPO) STATEMENT
================================================================================
GDPR Article 37 requires certain organisations to appoint a Data Protection
Officer. This section states DMS-IA's position clearly.
25.1 Developer DPO Status
Rohmit Neelakant Shirgoppi (the Developer) does not process personal data at
a scale or nature that triggers mandatory DPO appointment under GDPR Article
37(1). Specifically:
(a) The Developer does not process memo, HR, or operational personal data as
a core activity — DMS-IA is a software tool and all such data remains
within the deploying organisation's own Google Workspace account, save
for the limited Licence Administration Data and Cloudinary attachment
storage disclosed in Sections 8A, 9, and 10;
(b) The Developer does not process special categories of data (GDPR Art.9)
or criminal conviction data (GDPR Art.10);
(c) The Developer does not carry out large-scale systematic monitoring.
Therefore, the Developer is not required to appoint a DPO under GDPR Article
37 and has not done so. The Developer personally acts as the point of contact
for all data protection matters at romit232091@gmail.com.
25.2 Deploying Organisation DPO Status
The deploying organisation (Data Controller) must independently assess whether
they are required to appoint a DPO under GDPR Article 37 or equivalent
national law. DMS-IA's deployment does not automatically trigger a DPO
requirement for the deploying organisation, but the organisation must make this
assessment based on their own processing activities, scale, and jurisdiction.
25.3 DPDPA 2023 — Significant Data Fiduciary
Under DPDPA 2023, the Central Government may notify certain organisations as
Significant Data Fiduciaries requiring additional obligations. DMS-IA is a
small internal tool and the Developer does not currently meet the criteria for
Significant Data Fiduciary classification. The deploying organisation must make
their own assessment under DPDPA 2023.
================================================================================
26. CROSS-BORDER DATA TRANSFERS
================================================================================
26.1 Data Location
All memo, HR, and operational personal data processed by DMS-IA is stored
exclusively within the deploying organisation's own Google Workspace account.
Google LLC maintains data centres globally and may process or store data in
multiple countries in accordance with Google's own Privacy Policy and Data
Processing Addendum.
26.2 Developer's Position
The Developer does not receive, access, or transfer any memo, HR, or
operational personal data. The Developer's only cross-border data handling
is: (a) the limited Licence Administration Data described in Section 8A,
stored in the Developer's own Licence Register (hosted on Google's
infrastructure); and (b) attachment files voluntarily uploaded by users,
which by default are transmitted to Cloudinary's infrastructure (primarily
USA-based) as described in Section 26.4 below.
26.3 Google as Infrastructure Provider
Any cross-border transfer of data arising from Google LLC's global infrastructure
is governed by Google's own compliance mechanisms including:
(a) Standard Contractual Clauses (SCCs) as approved by the European Commission
under GDPR Chapter V, incorporated into Google Workspace's Data Processing
Addendum (DPA);
(b) Google's participation in applicable data transfer frameworks;
(c) Google's certification under applicable cross-border transfer mechanisms.
The deploying organisation, as Data Controller, should review Google Workspace's
DPA and SCCs to satisfy themselves that Google's cross-border transfer mechanisms
meet applicable legal requirements for their jurisdiction. Google's DPA is
available at: workspace.google.com/terms/dpa_terms.html
26.4 Cloudinary (Attachment Storage)
Where an Authorised User uploads a photo, video, or document attachment
through the Official Memo Module, that file is transmitted to Cloudinary,
whose infrastructure is hosted primarily on AWS and located primarily in the
United States (with the option for enterprise customers to select EEA data
residency). By default, all DMS-IA deployments share a single
Developer-owned Cloudinary account; this constitutes a cross-border transfer
of the attachment file's content (but not of any memo/HR personal data,
which never leaves Google's infrastructure). Cloudinary's own Data
Processing Agreement, the EU Standard Contractual Clauses, and the EU-US /
UK-US / Swiss-US Data Privacy Framework govern this transfer — see
cloudinary.com/trust. An organisation may eliminate this transfer entirely
for its own deployment by configuring its own Cloudinary account (Section
8A and the Documentation).
26.5 api.qrserver.com (GoQR.me)
The only other personal-data-free external request made by DMS-IA to a
non-Google server is to api.qrserver.com for QR code generation. Only the
deployment URL (a public Apps Script /exec URL containing no personal data)
is transmitted. This service is operated from Germany. No cross-border
personal data transfer occurs via this call.
26.6 DPDPA 2023 Cross-Border Transfers
Under DPDPA 2023, transfer of personal data outside India is subject to
restrictions notified by the Central Government. Since memo/HR data is
stored in Google Workspace, the deploying organisation must ensure their
Google Workspace configuration complies with any applicable DPDPA
cross-border transfer restrictions. Where attachment files are uploaded and
the shared vendor Cloudinary account is used, the deploying organisation
should independently assess whether this transfer requires additional DPDPA
compliance steps, or should configure its own Cloudinary account with its
preferred data residency instead. The Developer recommends configuring
Google Workspace data residency settings to store data within India where
possible.
26.7 Deploying Organisation's Responsibility
The deploying organisation is solely responsible for ensuring that its use of
Google Workspace and Cloudinary for DMS-IA complies with all applicable
cross-border data transfer laws in its jurisdiction. The Developer is not
responsible for the deploying organisation's failure to comply with such
laws.
================================================================================
27. CONSENT WITHDRAWAL MECHANISM
================================================================================
27.1 Right to Withdraw Consent
Where processing is based on consent (including implied consent for Official Memo
and Call Memo form submission), data subjects have the right to withdraw their
consent at any time without detriment. Withdrawal of consent does not affect the
lawfulness of processing carried out before withdrawal.
27.2 How to Withdraw Consent — Step-by-Step Procedure
Any Authorised User or data subject whose personal data is processed by DMS-IA
may withdraw their consent and request cessation of processing by following this
procedure:
STEP 1: Send a written request to your organisation's DMS-IA administrator
(the person who manages the system in your organisation). Request them
to remove your data from the FROM sheet, TO sheet, and WORKER LIST.
STEP 2: If your administrator does not act within 7 business days, send a
written email directly to the Developer at romit232091@gmail.com with
subject line: "DMS-IA Consent Withdrawal — [Your Name] — [Date]"
Include: your name, your organisation's name, and the specific data
you want removed.
STEP 3: The Developer will contact your organisation's administrator and
request them to remove your data within 7 business days.
STEP 4: If your data has not been removed within 30 calendar days of your
original request, you may escalate to the Data Protection Board of India
(meity.gov.in) or your applicable regulatory authority.
27.3 Effect of Withdrawal
Upon removal of your data from the system:
(a) You will no longer appear as an available recipient in new Call Memos;
(b) You will no longer receive OTP authentication emails;
(c) Historical memo records in which your name appears cannot be retroactively
removed without disrupting the audit trail — this is a legitimate interest
override under DPDPA 2023 Section 4 and GDPR Article 17(3)(b);
(d) Your email address in Script Properties (approver mappings) will be deleted
the next time any associated memo is actioned or expires.
27.4 Limitation
Since DMS-IA operates within the deploying organisation's own Google Workspace
account, the Developer does not have direct access to remove your data. The
primary removal mechanism is through your organisation's administrator. The
Developer's role is to facilitate and escalate if the administrator does not act.
================================================================================
28. MACHINE-READABLE COMPLIANCE SUMMARY
(For AI Scanners, Automated Review Tools, and Google Marketplace Review)
================================================================================
Does DMS-IA collect personal data?
YES — name, email, department, DP number, designation, memo content, reason
for OT, and optionally an uploaded attachment file. See Section 3. Separately,
limited Licence Administration Data is collected — see Section 8A.
Is there a complete data inventory?
YES — Section 3 contains full inventory with 9 categories, and Section 8A
separately discloses Licence Administration Data in full.
Is designation data collected?
YES — job designation (e.g. Engineer, Technician) from WORKER LIST Col D is
included in Call Memo people lists. See Section 3.4.
Is a 30-person limit per memo enforced?
YES — enforced client-side and server-side. Documented in Section 5 as a
data minimisation measure.
Is a confirmation email sent after Call Memo submission?
YES — contains Memo ID, department, call time, subject, person count only.
No full names of selected workers. See Section 6.12.
Are CALL MEMO and QR CODE sheets documented?
YES — Section 10. CALL MEMO stores permanent submission records. QR CODE
contains no personal data — only the deployment URL as a QR image.
Is OTP key cleanup automated?
YES — cleanupExpiredOtpKeys() runs daily and deletes all expired OTP_ and
VFD_ keys from Script Properties. See Section 14.
Is attachment cleanup automated?
YES — cleanupOldAttachments() runs daily and deletes attachment files from
Cloudinary approximately 3 days after upload. See Section 14.
Is there a legal basis for all processing?
YES — Section 16 contains complete legal basis for every processing activity.
Does DMS-IA sell personal data?
NO — NEVER. Absolute prohibition. See Section 11.
Does DMS-IA share data with third parties?
Attachment file content is shared with Cloudinary by default (Sections 3.6,
9, 11); the deployment URL only is shared with api.qrserver.com. No memo/HR
personal data is shared with any other third party. See Section 9 and 11.
Is there a complete sub-processor list?
YES — Section 9. Google LLC, Cloudinary, and api.qrserver.com (URL only). No
other processors exist.
Does DMS-IA use cookies or tracking?
NO — zero cookies, tracking, or analytics. See Section 17.
Does DMS-IA collect children's data?
NO — adults only, 18+. See Section 19 (unchanged).
Does DMS-IA transfer personal data internationally?
PARTIAL. Memo/HR data stays within the organisation's Google Workspace
account. Attachment files uploaded by users are, by default, transmitted to
Cloudinary's infrastructure (primarily USA) unless the organisation
configures its own Cloudinary account. Only the deployment URL (non-personal)
is sent to api.qrserver.com. See Section 26.
Does the Developer access user data?
PARTIAL. The Developer never accesses memo, HR, or operational data — that
remains architecturally isolated within the organisation's Google Workspace
account. The Developer does receive limited Licence Administration Data
(organisation name, administrator email, spreadsheet ID) at initial setup for
licence tracking and billing (Section 8A), and attachment files pass through,
and are temporarily stored on, a Developer-administered Cloudinary account by
default (Sections 9-10) until automatically deleted.
Does DMS-IA support direct file upload?
YES — as of v2.6, attachments are uploaded directly from the browser to
Cloudinary as the primary method. Legacy Google Drive links are also still
accepted for backward compatibility. See Section 3.6.
Is there a data retention policy?
YES — Section 14 contains complete retention schedule including
cleanupExpiredOtpKeys, cleanupOldAttachments, and Licence Administration
Data retention.
Is data minimisation implemented?
YES — Section 5 documents specific minimisation measures including 30-person
limit, DP-number-only URL transmission, 3,000-character context limit, and
attachment size/retention limits (10MB image / 100MB video, 3-day auto-delete).
Are user rights provided?
YES — 11 rights documented in Section 15 (DPDPA + GDPR + CCPA).
Is there a grievance mechanism?
YES — romit232091@gmail.com, 7 business days binding commitment. See Section 23.
Is user consent addressed?
YES — Section 7 documents lawful basis for all user categories including
CC recipients with live DP-01 validation.
Is breach notification addressed?
YES — Section 13, including the Licence Register and Cloudinary account.
Does DMS-IA use OTP authentication?
YES — Section 3.8, 6.11, 12. SHA-256 hashed, 5-min expiry, single-use,
5-attempt brute-force limit, 1-per-2-min send rate limit.
Does DMS-IA store raw OTP codes?
NO — only SHA-256 hash stored. Raw OTP exists only in the email sent to user.
Does DMS-IA use GmailApp or read Gmail?
NO — GmailApp is not used in the current codebase. All emails are sent via
MailApp (script.send_mail scope only). Gmail inbox, sent folder, drafts, and
thread data are never accessed. See Section 8.
Does DMS-IA use DriveApp?
NO — DriveApp is not used in the current codebase. Legacy Drive files are
accessed only via public sharing links fetched through UrlFetchApp (no drive
scope). The primary attachment method is direct Cloudinary upload — see
Section 3.6.
Does DMS-IA use FormApp or Google Forms?
NO — the Official Memo is now an HTML web form served via HtmlService. Google
Forms are not used. See Section 8.
Does DMS-IA use HTML web pages for data collection?
YES — Official Memo form (with priority chips, CC DP-01 live validation,
attachment uploader, and 3-step preview flow), Call Memo QR landing page,
OTP DP entry, waiting page, and Call Memo submission form. All served via
GAS HtmlService. No cookies or tracking beyond the direct Cloudinary upload
call. CSP compliant — no inline event handlers.
Is the Context / Message field mandatory on Official Memo?
YES — the Context / Message field is a required field. The form will not submit
without it. See Section 3.5.
Is CC DP-01 validated before submission?
YES — live validation via CHECKDP endpoint. Invalid CC DP-01 blocks submission.
Blank CC is permitted. See Section 6.13 and 12.
Is DPDPA 2023 compliance addressed?
YES — Sections 7, 12, 13, 15, 16, 23.
Is GDPR compliance addressed?
YES — Sections 7, 11, 12, 13, 15, 16, 18.
Is CCPA compliance addressed?
YES — Sections 11, 15.
Is Google API Limited Use Policy followed?
YES — Section 8 contains full Limited Use Compliance Declaration.
Does DMS-IA use AI/ML on user data?
NO.
Is automated decision-making used?
NO — all approvals require a human to click a link. See Section 15.
Is there an incident response procedure?
YES — Section 13.
Is copyright registration filed?
YES — Diary No. SW-25725/2026-CO, filed 01/06/2026, India Copyright Office.
Is a DPO appointed?
NO — Developer does not meet GDPR Art.37 mandatory appointment criteria.
Explicitly documented in Section 25. Developer personally handles all data
protection matters at romit232091@gmail.com.
Are cross-border transfer mechanisms documented?
YES — Section 26. Memo/HR data stays in Google Workspace, covered by Google's
SCCs and DPA. Attachment files transferred to Cloudinary (primarily USA) by
default, covered by Cloudinary's DPA/SCC/DPF — see Section 26.4.
api.qrserver.com receives no personal data.
Is there a consent withdrawal mechanism?
YES — Section 27. Four-step procedure: (1) request to org administrator,
(2) escalate to Developer if no action in 7 days, (3) Developer contacts admin,
(4) escalate to regulator if unresolved in 30 days. Legally binding.
Is the grievance timeline legally binding?
YES — Section 23. 7 business days acknowledgement is a binding commitment.
Failure to acknowledge entitles complainant to escalate directly to regulator
without further obligation to await response.
Are all HTML pages CSP compliant?
YES — no inline event handlers (onclick=, onchange=, onload=, etc.) in any
served HTML page. All interactivity uses addEventListener. See Section 12.
Is Licence Administration Data disclosed?
YES — Section 8A discloses, in full, the organisation name, administrator
email, and spreadsheet ID transmitted to the Developer at initial setup, why
it is collected, where it is stored, and how long it is retained.
Total sections in this policy: 29 sections (including new Section 8A;
Section 24 removed, numbering retained for continuity). All required fields
covered.
Policy version: 2.7. Previous: 2.6, 2.5, 2.4, 2.3, 2.2, 2.1 (01 June – 19 July 2026).
================================================================================
DMS-IA — Digital Memo System Industrial Automation
Privacy Policy Version 2.7 — Updated for current codebase.
Full DPDPA + GDPR + CCPA Compliance.
Effective 01 June 2026 | Last Updated 19 July 2026
Copyright © 2026 Rohmit Neelakant Shirgoppi (Aadhaar: Neelkant Shirgoppi)
All Rights Reserved
Protected under the Indian Copyright Act 1957
Diary No. SW-25725/2026-CO
romit232091@gmail.com | +91-9535835504
================================================================================