Information Security Policy
Our clients trust us with their code, their data and their ideas. This policy sets the core rules that keep information confidential (only the right people can see it), accurate (nobody changes it without authority) and available (it is there when it is needed).
Document
Policy number
TSS-IT-02
Version
1.0
Effective from
1 September 2026
Next review
March 2027
Owner
IT Team
Approved by
Board of Directors
Applies to
Every employee, trainee and intern, and anyone else with access to TSS information, systems or devices, including contractors. It covers all TSS information in any form.
Issued by
Thakur Systems & Structures Private Limited, CIN U62011PN2026PTC254650
Related policies
Acceptable Use Policy (TSS-IT-01), Password and Authentication Policy (TSS-IT-03), Access Control Policy (TSS-IT-11), Data Privacy and Management Policy (TSS-IT-04), Incident Response Policy (TSS-IT-05), Disaster Recovery and Business Continuity Policy (TSS-IT-08)
OVERVIEW
The other IT policies build on it.
1. WHO IS RESPONSIBLE
The Board of Directors is accountable for information security overall, approves this policy, and decides on major risks.
The IT team runs security day to day: devices, accounts, access, backups, monitoring and incident response. It also keeps these policies up to date.
Team leads make sure their teams follow the policies, approve access requests, and raise risks.
Everyone follows the policies, protects the information they handle, and reports anything suspicious.
2. CLASSIFYING INFORMATION
All information falls into one of four levels. If you are not sure which level applies, treat it as Confidential.
| LEVEL | EXAMPLES | HOW TO HANDLE IT |
|---|---|---|
| Public | Published website content, public marketing, open-source code we have released | Can be shared freely |
| Internal | Internal processes, team calendars, general project notes | Share within TSS only; not outside without approval |
| Confidential | Client source code and designs, contracts, pricing, business plans, employee records | Only people who need it; approved company storage only; never in personal accounts or unapproved tools |
| Restricted | Passwords, keys and other secrets; production databases; ID numbers, bank details and health information; client data the contract marks as restricted | Named people only; strongest controls; access logged; no copies on laptops unless the IT team approves |
3. CORE SECURITY RULES
Devices. Company devices are managed by the IT team, with full-disk encryption, a screen lock after five minutes, a supported and up-to-date operating system, anti-malware software, and remote lock and wipe in case of loss.
Updates. Install security updates promptly: critical updates within 7 days of release, and others within 30 days. The IT team may install updates automatically.
Accounts. Everyone has their own account. Multi-factor authentication is required wherever it is available (Password and Authentication Policy).
Access. You get access only to what your role needs, and it is removed when you no longer need it (Access Control Policy).
Storage. Keep work only in approved company systems. Do not keep Restricted data on your laptop unless the IT team has approved it.
Encryption. Data is encrypted in transit (HTTPS, TLS and SSH) and at rest on devices, in backups and in cloud storage.
Secrets. Passwords, API keys and tokens are kept in the approved password manager or secrets store, and never in code, chat, email or documents.
Backups. Critical data is backed up and the backups are tested (Disaster Recovery and Business Continuity Policy).
Logs. Security logs from company systems are kept for at least one year, and can be produced to CERT-In or other authorities when the law requires.
Clocks. System clocks are synchronised with a reliable time source, such as the time servers of the National Informatics Centre (NIC) or the National Physical Laboratory (NPL), so that logs line up if we ever need to investigate.
Clean desk and screen. Lock your screen whenever you step away. Do not leave confidential papers on desks, and shred paper you no longer need.
Physical security. The office is locked when nobody is there. Visitors are signed in and accompanied. Do not let people you do not know follow you in.
Suspicious messages. Treat unexpected links, attachments and requests for money or credentials with suspicion, and check them another way before acting.
Secure development. Code is reviewed and tested before release (Software Development and Change Management Policy).
Vendors. Before we use a new vendor or cloud service that will handle our data or our clients’ data, the IT team checks its security (Cloud and App Use Policy).
Client rules. Where a client contract sets stricter security rules, those rules apply to that client’s work.
4. MANAGING RISK
The IT team keeps a simple risk register: what could go wrong, how likely it is, how bad it would be, and what we are doing about it. The register is reviewed at least every six months, and whenever something significant changes, such as a new client, a new system or an incident.
5. LEGAL AND CONTRACT REQUIREMENTS
We follow the Information Technology Act, 2000, the directions issued by CERT-In (including reporting certain cyber incidents to CERT-In within six hours of noticing them), the Digital Personal Data Protection Act, 2023 and its rules, and the security terms in our client contracts.
6. EXCEPTIONS
If you need to do something this policy does not allow, ask the IT team in writing first. Approved exceptions are recorded, have an end date, and are reviewed.
7. REPORTING
Report any security incident, weakness or suspicious activity to the IT team immediately (Incident Response Policy). Do not test or try to exploit a weakness yourself.
8. BREACHES
Breaking this policy may lead to disciplinary action, and to your access being removed while the matter is looked into.