Information Security Policy — Kaizer CRM
KAIZER Salon · 1019 Avenue P, Unit 303, Brooklyn, NY 11223
Owner and person responsible for information security: Volha Safonava
Last updated: August 27, 2026 · Reviewed at least annually and after any material change
0. Approval
This policy is issued and approved by Volha Safonava, Owner of Kaizer inc, who holds
management responsibility for the business and is accountable for information security.
Approved on 27 August 2026. Approval is renewed at each review, and the policy is reviewed at
least once a year and whenever something material changes — a new integration, a new class of
data, a change of hosting, or an incident.
1. Scope and purpose
This policy covers Kaizer CRM, the salon-management application operated by KAIZER Salon, the
server it runs on, and the data it holds: client contact details and service history, appointments,
payment records, inventory and vendor records, and bank transactions imported for our own
bookkeeping. The application is internal. It is not sold, not offered to the public, and has no
consumer sign-up. Its users are the owner and a small number of named staff.
2. Responsibility
The owner is accountable for information security, approves who gets access, and decides on any
change that affects how data is stored or shared. There is no separate security department; with
three users and one server, the owner performs these duties directly.
3. Access control
- Every user has a named account. Shared accounts are not used.
- Passwords are never stored. Only a bcrypt hash is kept, so the database does not reveal them.
- Access is role-based and enforced on the server, not just hidden in the interface: the
advertising role sees only Leads and cannot delete them; a stylist sees only their own
payments; inventory, purchasing and accounting are restricted to the owner.
- Two-step sign-in is available: after the password, a six-digit code is emailed, valid for ten
minutes and single-use. A confirmed device may be remembered for 30 days and can be revoked
at any time from Settings.
- Accounts are removed by the owner as soon as a person stops working with the salon.
4. Server and network
- One dedicated server, located in the United States.
- Administrative access is by SSH public key only; password authentication is disabled on the
server. The private key is held by the owner.
- The application is served only over HTTPS. TLS 1.2 and 1.3 are permitted; TLS 1.0 and 1.1 are
refused. Certificates are issued by Let's Encrypt and renew automatically.
- A firewall limits the ports that are reachable from the internet.
- Operating-system security updates are installed automatically every day.
3a. Access control policy
Who may reach what, and how that is granted, changed and removed:
- Named accounts only. Every person who uses the application has their own account.
Shared or generic logins are not issued.
- Least privilege by role. Three roles exist and each sees only what its work needs:
admin — full access, held by the owner; master — only their own appointments
and payments; ads — only the leads list, with no ability to delete. Role limits are
enforced on the server, not merely hidden in the interface.
- Granting access. Only the owner creates accounts and assigns roles, in Settings →
User management. A new account is created with the narrowest role that fits the job.
- Changing access. A change of duties means a change of role, made by the owner on the
day the duties change.
- Removing access. When someone stops working with the salon, the owner deletes their
account the same day and revokes any remembered devices. With three users this is done by
hand and takes under a minute; there is no automated de-provisioning system.
- Authentication. Passwords are stored as bcrypt hashes, never in plain text. The
owner's account requires a second step: a six-digit one-time code sent by email, valid ten
minutes and single-use. A confirmed device is remembered for thirty days.
- Server access. Administrative access to the server is by SSH public key only;
password login is disabled at the server level. The private key is held by the owner.
- Quarterly review. Once a quarter the owner reviews the list of accounts, their roles
and remembered devices, removes anything no longer needed, and records the date of the
review. This is done together with the software end-of-life check.
4a. Software lifecycle and end-of-life (EOL)
Software that no longer receives security updates is a liability, so we keep track of what we
run and when its support ends:
- The server runs an Ubuntu Long Term Support release. The current one, 24.04 LTS, is
supported with security updates until June 2029.
- The application runs on Python and a small, fixed set of libraries installed in one virtual
environment on that server. Their versions are recorded and upgraded together with the
platform.
- The owner reviews the list of installed software and its end-of-support dates at least
once every quarter, at the same time as the review of user accounts, and records the
date of the check.
- Anything approaching end of support is upgraded or replaced before that date, not
after it. The operating system is migrated to the next LTS release well ahead of June 2029.
- Operating-system security updates are installed automatically every day in the meantime, so
supported software stays patched without waiting for the quarterly review.
5. Encryption and secrets
- All traffic between browsers and the server is encrypted in transit.
- Bank data obtained through Plaid — access tokens and transaction descriptions — is encrypted
at rest in the database using authenticated encryption (Fernet, AES). A copy of the database
alone reveals nothing about the bank.
- The encryption key and all API credentials live in files readable only by root. They are never
sent to the browser and never appear in the application interface.
- Credentials for banks and payment providers are entered in those providers' own windows.
The application never sees, transmits or stores them.
6. Third parties
The application exchanges data with a small number of named services, each for one purpose:
Plaid for importing our own bank transactions; Square for card payments; Resend for sending email
to our own clients; Google Calendar for staff schedules. No client or bank data is sold, shared for
advertising, or used to build profiles.
7. Backups and recovery
- The database is backed up daily; 30 days of copies are kept.
- Encryption keys and service credentials are backed up separately and are deliberately kept
out of off-site storage, so that ciphertext and its key never sit in the same place.
- Off-site copies of the database and client photographs are stored with an independent cloud
provider.
8. Change management
Changes are prepared and tested against a copy of live data before they are applied. Each change
is checked for syntax errors and verified after deployment. The database is backed up immediately
before any change that alters its structure.
9. Retention and deletion
Records are kept only as long as there is a reason to keep them. How long that is, by type:
| Data |
Kept for |
Why |
|---|
| Client card and service history |
While a client, then 3 years |
Repeat visits, aftercare, disputes |
| Signed contracts and consents |
7 years |
Legal and liability record |
| Payments, invoices, purchases, inventory |
7 years |
Tax and bookkeeping obligations |
| Bank transactions imported through Plaid |
7 years |
Same books they belong to |
| Bank access tokens |
Until disconnected |
Deleted the moment a bank is unlinked |
| Leads that never became clients |
2 years |
Follow-up window |
| Email and SMS logs |
2 years |
Proof of what was sent |
| Sign-in codes |
10 minutes |
Expire and are single-use |
| Remembered devices |
30 days |
Expire on their own |
| Database backups |
30 days |
Recovery from failure or mistake |
Deletion on request. A client may ask us to correct or delete their personal data by
writing to the address below. We answer within 30 days. We delete what we are free to delete and
keep only what the law requires us to hold — signed contracts and the financial record of what was
paid — telling the client plainly what was kept and why.
Deletion in the ordinary course. Disconnecting a bank or accounting integration deletes
the stored access token at once and revokes the connection at the provider. Expired sign-in codes
and remembered devices fall away automatically. Backups older than thirty days are removed
automatically, so deleted data does not survive indefinitely in copies.
Review. The owner reviews this schedule at least once a year, together with the review of
accounts and software, and adjusts it if the law or the way the salon works changes.
10. If something goes wrong
On any sign of unauthorised access, the owner will: revoke the affected credentials and tokens
immediately; disconnect the affected integrations; change passwords and rotate keys; check the
server and application logs to establish what was reached; restore from backup if data was altered;
and notify affected clients and the relevant providers where required by law.
11. What we do not do
Stated plainly, so this document is not read as claiming more than is true: we do not hold SOC 2
or ISO certification, do not run automated vulnerability scanners, do not commission penetration
tests, and do not operate a bug-bounty programme.
Contact: office@kaizersalon.com · +1 (347) 907-7077