Information security policy

This policy covers Fohrkast's own service: the application at fohrkast.com, its Amazon Web Services account, its domain and email, its source code and release process, and the devices used to run it. It covers the records Fohrkast holds for each business as that business's Data Processor, and the details of Fohrkast's own users.

Fohrkast is built and operated by one person, its founder, who owns this policy and is responsible for information security. Where a rule needs a second person, it names the role.

A breach at a business that uses Fohrkast is that business's incident. Fohrkast's part in it is set out in the processor agreement (fohrkast.com/dpa).

• » Hold the least. Each duty decides what is kept. Personal details are sealed per person, and audit records carry references, never the details.
• » Keep it in India. Servers, database, backups and logs run in AWS Mumbai, with backup and audit copies in Hyderabad.
• » The business decides. Fohrkast prepares and records; the business sends notices and filings. Fohrkast staff do not open a business's records in the normal course.
• » Prove, do not assert. Every step is written to a hash chained record that a business can check without trusting Fohrkast.
• » Say what is not in place yet. The last section of this policy lists it.

Records held for a business never leave production. Development and tests use invented data on throwaway databases, and the demo companies' data is invented.

• » A business's people get access by seat, each a fixed set of permissions. Seats that open sealed details, approve steps, make API keys or act for many businesses sign in with an authenticator app; five wrong codes in a row lock the account for 15 minutes.
• » Every sign in to Fohrkast's staff console needs a password and an authenticator app code, and a staff session lasts at most 12 hours.
• » Fohrkast staff do not open a business's records in the normal course. Emergency access needs a recorded reason and a time limit, is used by a person only, and shows in the business's own log.
• » There is no SSH to the server. People reach it through AWS Session Manager, and every session is logged for one year. The database has no public address.
• » AI coding and drafting tools used to build Fohrkast never hold production credentials or customer data.
• » Every three months, access is reviewed: staff seats, emergency access grants, API keys and the AWS accounts that can change production. Anything no longer needed is removed, and the review is recorded.

Data is encrypted at rest and in transit, with keys held in AWS KMS in Mumbai and a replica of the data key in Hyderabad for the backup copy. Each person's sealed details have their own key; destroying that key makes them unreadable, which is how an erasure reaches the backups. The algorithms, key sizes and TLS settings are listed on fohrkast.com/trust.

Keys, links and tokens Fohrkast issues are random values of 384 bits.

• » Every change is made in the source repository and passes its automated tests before release.
• » Each release is built from a commit, its SHA-256 checked on the server before it is unpacked, and switched back automatically if the health check after the switch fails.
• » Every page carries a Content Security Policy that allows only this site's own scripts, styles, fonts and images.
• » Public pages, legal pages and rulebook releases go live only with the founder's approval. A rulebook release also needs a second person's approval of the exact text released.
• » The server applies Ubuntu's security updates unattended, and the database takes PostgreSQL minor upgrades automatically. The code libraries the service uses are checked for known vulnerabilities at least once a month and before each release that changes them.

• » Logs are kept one year in AWS Mumbai. Records of account activity are write locked for one year, with a copy in Hyderabad.
• » Every event in a workspace sits on a hash chained audit trail in a published format (fohrkast.com/law/hash-v1). Each night the chain's fingerprint is sealed by independent timestamp services in four countries (fohrkast.com/trust/seal).
• » Alarms go to a mailbox outside AWS: any use of the AWS root login, high severity findings from AWS threat detection, and problems found by the nightly checks of the audit trail and its timestamps.
• » Server clocks follow the time servers of NIC and NPL (CERT-In Directions, 28 April 2022).

Every sub processor that handles personal data for Fohrkast is listed on fohrkast.com/sub-processors with what it does and where it runs. Businesses get notice before a new one receives personal data, and may object. Each is held to obligations no less protective than the processor agreement's.

Fohrkast prefers suppliers that keep data in India. One that does not is shown as outside India on the list.

• » An incident on Fohrkast's own systems is handled by Fohrkast's incident runbook. The time it was noticed is written down first. Evidence is preserved: no log is deleted or its retention changed, and a server or database is snapshotted before it is replaced. Then access is contained.
• » Fohrkast reports cyber incidents on its own systems to CERT-In within 6 hours of noticing them, and tells each affected business without delay and within 24 hours of detection, as the processor agreement sets out.
• » Within 7 days, the cause, the fixes and how a repeat is prevented are written up, and this policy is changed if it needs to be.
• » Security reports from outside go to tech@fohrkast.com. How they are handled is on fohrkast.com/security.

• » Database backups are taken daily and kept 7 days in Mumbai. An encrypted copy is kept 35 days in Hyderabad.
• » A restore from the Hyderabad copy is drilled once a month and after any change to the database setup. Restore tested on production on 26 Oct 2026: the encrypted backup copy in Hyderabad was restored into a separate private database in 25 minutes; the newest restorable point was 12 minutes old.
• » The database runs in one availability zone in Mumbai. If it fails, the service is restored from backup, and the restore test shows how long that takes.
• » When the founder is away, the service keeps running; rulebook updates, advisories and support replies wait for his return.

• » The devices used to run Fohrkast have full disk encryption, a screen lock and current security updates, and are not shared.
• » Every account that can change Fohrkast's service (AWS, the domain, email, the code repository and the payment gateway) has a unique password from a password manager and a second factor. The AWS root login is not used day to day, and any use of it raises an alarm.
• » A lost or stolen device is an incident: its sessions and keys are revoked the same day.
• » These device and account rules are checked every three months.

Logs are kept one year. Backups are kept 7 days, and the encrypted copy 35 days. Records held for a business are kept and erased as the processor agreement sets out. When a person's details are erased, their key is destroyed, so the copies in backups can no longer be read and the backups themselves are gone within 35 days.

• » No certification against a security standard.
• » No penetration test by an outside firm.
• » No recovery time or recovery point targets; the restore test is the measured figure.
• » The database runs in one availability zone.

This policy is reviewed every six months, after any incident and after any major change to the service. The version and date of each change are shown at the top of this page.