Information Security Policy

This policy states how information is protected across the systems I run, so that a third party assessing them has a written reference rather than an inference from configuration. It is the parent document for the Access Control Policy and the Data Retention and Deletion Policy.

I am solely responsible for information security across all systems in scope. That includes designing controls, applying them, monitoring them, and responding to incidents. Security correspondence goes to security@kanishksachdev.com, an address on a domain I control and monitor.

Because responsibility is not delegated, the usual separation of duties is not achievable. The compensating control is that changes are made through version-controlled configuration rather than by hand, so every change to a production system is recorded, attributable, and reversible.

The systems in scope are enumerated in a single private repository that defines all of them. An asset that is not described there is not deployed. The inventory covers:

• Hosts: five servers running containerized workloads, plus one managed workstation. Each has a documented role, owner account, and network position.
• Applications: every deployed service is declared in a Docker Compose file held in source control, pinned to an explicit image version and content digest.
• Data stores: each application database and persistent volume, with its backup status recorded.
• Third party accounts: hosting, DNS and CDN, source control, private network, secrets management, and financial data providers.

Access to production systems is governed by the Access Control Policy, which covers the zero trust network model, centralized identity, multi-factor authentication requirements, least privilege, periodic access reviews, and revocation. In summary: there is no implicitly trusted network, every administrative interface requires an authenticated identity with a second factor, and credentials are scoped to the narrowest function that works.

In transit. All external traffic is HTTPS only, with certificates issued by Let's Encrypt and renewed automatically. Plain HTTP is redirected at the edge. TLS 1.0 and TLS 1.1 are refused. Only TLS 1.2 and TLS 1.3 are accepted, using AEAD cipher suites with ephemeral key exchange. Administrative traffic additionally travels inside an encrypted WireGuard tunnel.

At rest. Financial account data retrieved from third party providers is encrypted at the application layer with AES-256-GCM before it is written to the database. Encryption keys are supplied at deploy time from the secrets manager and are never committed to source control. Databases are reachable only from the internal container network of their host and are not published to the internet. Backups are encrypted independently with their own passphrase.

Secrets. Application secrets live in a self-hosted secrets manager and are rendered onto hosts at deploy time. No secret is stored in source control. The identity used by automation to read them is read-only and scoped to that purpose.

Only one host exposes ports to the public internet, and only those required to serve web traffic and mail. All other services are reachable exclusively over a private WireGuard network that authenticates each device before it can route. Administrative interfaces are not published publicly. Inter-host management traffic uses read-only, purpose-scoped credentials rather than shared administrative accounts.

• Operating system security updates are applied automatically and unattended on all production hosts.
• Application and container dependencies are monitored continuously by a self-hosted Renovate instance, which opens update pull requests for review.
• Container images are pinned to explicit versions and content digests, so an image cannot change beneath a deployment without a reviewed commit.
• A separate monitoring service tracks upstream releases across every running container and reports version drift.
• A host-based intrusion detection system inspects web and SSH logs and automatically blocks malicious source addresses.

I do not operate an endpoint scanning program for personal machines. With no employees or contractors, the endpoint fleet is a single workstation under full disk encryption with automatic OS updates enabled.

Container logs from every host are shipped to a central log store and retained for query. Metrics are collected fleet-wide and evaluated against alerting rules, with alerts delivered to a push notification channel I receive directly. Backup jobs alert on failure rather than on success, so a silent backup is a detected condition rather than an assumed one.

The primary application host is backed up hourly to encrypted offsite storage using Borg, covering the full filesystem and the container volume tree. Repository integrity is verified on an automated weekly schedule. Retention follows the schedule set out in the Data Retention and Deletion Policy.

Known limitation, stated rather than omitted: database dumps are not currently quiesced before the snapshot is taken, so a restore of a running database is best effort. Secondary hosts are not yet backed up. Neither gap affects financial data, which is held on the primary host and is reconstructible from the upstream provider on reconnect.

An incident is any suspected unauthorized access, credential disclosure, or loss of data integrity. The response sequence is:

• Contain. Revoke the implicated credential or device from the identity provider, which removes access across every dependent system at once.
• Assess. Review central logs and intrusion detection records to establish what was reached and when.
• Eradicate and recover. Rebuild the affected host from version-controlled configuration, restore data from the encrypted backup set, and rotate every secret the host could read.
• Notify. Where a third party provider is implicated, including any financial data provider, notify them promptly through their published security contact.
• Record. Write down the cause and the corrective change, and fold it into the configuration so the same failure cannot recur silently.

I rely on external providers for hosting, DNS and content delivery, source control, private networking, and financial data aggregation. Each is accessed through an account protected by multi-factor authentication. Credentials issued by these providers are treated as production secrets and handled under section 5. Financial data providers receive only the authorization required to read the accounts I link myself, and any connection can be revoked by me at any time.

This policy is reviewed annually and on any material change to the infrastructure, whichever comes first. A material change means adding a host, adding a service that processes financial data, or altering how access or encryption works. The effective date at the top of this page reflects the most recent review.