Security and deployment
Your server, your database, your policy.
KulturPro is installed wherever you decide. Below is what it brings for access control, what it records and what you need to run it. Also what it doesn’t include.
Access control
What happens before anyone sees a record.
In the order it happens, from typing the address to the query returning rows.
Sign in
- Passwords stored with Argon2, never in the clear
- Configurable policy for length, uppercase, digits and symbols
- History that prevents reusing the last passwords
- Account lockout after repeated failed attempts
- reCAPTCHA on the sign-in form
Confirm
- Second factor with an authenticator app or a code by email
- Email to the account holder when someone fails to sign in as them
- Forced password change on first sign-in
- Recovery with a single-use, expiring link
Pick a company
- The company is chosen at sign-in and travels in the session
- With no company in the session, queries return nothing
- Session renewal revalidates access to that company
- If access is revoked, the session is closed
Authorize
- Administrator, manager and user roles over screens and over the API
- Permissions per hierarchy node in the assets module
- The host suite’s permission map when running hosted
- Administrative operations require a reason and are recorded
Query
- The session travels in a cookie that scripts cannot read
- Cross-site request forgery protection with a double cookie
- Rate limits on sign-in, webhook and AI generation
- Dashboard queries can run under a read-only database login
Architecture
Where each piece sits.
A typical Windows Server deployment: the site, the API as a child application and the database behind, exposing nothing more than necessary.
Application server
Windows Server with IIS: the site at the root and the API as a child application at /api.
SQL Server
The product database, 2019 or later, reachable only from the application server.
Attachments
A server folder outside the published site, which must be part of your backup policy.
Deadline watcher
Checks due dates and fires the alerts, one pass per company.
Minor edits
Releases the process starts queued while an edit was open.
Preventive maintenance
Raises the work orders for recurring plans.
Only what is needed
The site and the API are published over HTTPS. The webhook endpoint and the task links for outsiders are the only access without a session, and both are rate limited.
SendGrid or your own SMTP.
AI provider
Only if you enable assisted generation.
reCAPTCHA
Only if you enable it on sign-in.
Requirements
What it takes to install it.
| Component | Detail | Required |
|---|---|---|
| Server | Windows Server with IIS 10 or later and the ASP.NET Core 8 hosting bundle. | Yes |
| Database | SQL Server 2019 or later. The schema is applied with numbered, idempotent scripts. | Yes |
| Certificate | HTTPS on the site; the application redirects unencrypted traffic. | Yes |
| Outbound email | SendGrid or an SMTP server. Without it there are no deadline alerts and no links for outsiders. | Optional |
| AI provider | A provider key. Without one the application says so and is used by hand. | Optional |
| Read-only login | A restricted database login for the dashboard queries. | Optional |
| Browser | Any current one, on a computer or a phone. Nothing is installed on the user’s machine. | Yes |
Operations
How it is maintained.
Automated releases
Delivery runs through a workflow with manual approval for production; the same workflow serves several sites from one configuration file.
Backup before releasing
A production release takes a database copy before applying changes, and keeps the previous application version in case you need to go back.
Schema by scripts
Database changes ship as numbered scripts that can be re-run safely, applied as one more step of the release.
File logging
The application writes a daily log on the server; that folder belongs in your retention policy.
Separate environments
QA and production are different sites, each with its own database and its own configuration, which never travels in the repository.
Health endpoint
There is a check address for your load balancer or monitoring.
- Electronic signature of records: it does not exist in the product.
- Single sign-on, SAML, OIDC or Active Directory: users live in KulturPro.
- Encryption of data at rest: if you need it, it is solved in the database engine or on the disk.
- Scheduled backups from the application: the copy is your DBA’s job.
- Certifications: we claim no ISO 27001, SOC 2 or GxP compliance for this product.
Questions
About security and operations.
Can it be installed in the cloud?
Yes. What it needs is Windows Server with IIS and SQL Server; if that is in your cloud, it runs there. We depend on no particular managed service.
Who can see another company’s data?
Nobody from the application: the company filter sits in data access and a session without a company returns no rows. Whoever administers the database can, as in any system.
What happens when someone leaves the organization?
The account is deactivated and their tasks are reassigned in bulk, with a reason. The record of what they did is not deleted.
Do you store our data?
No. The installation is yours. If you grant us support access, it is with your credentials and under your rules.
Is it suitable for regulated pharmaceutical industry?
For administrative processes, yes. For records that require electronic signatures and GxP validation, no: that is covered by the InduBatch suite from the same maker.
Let’s review your deployment before promising dates.
In one session with your IT team we go over server, database, email and releases, and tell you what is missing.