Security and deployment
Every request passes through the same six layers.
From the moment someone signs in until a record is signed, these are the controls along the way. And below, the infrastructure it runs on.
Security layers
From identity to audit.
The order follows a real request: first who you are, then what you can do, and finally what gets recorded.
Identity
- Sign-in with Microsoft Entra ID or Active Directory, configured per company
- Local passwords stored with BCrypt, never in readable form
- Password policy: forced change, periodic change and account expiry
- Optional second factor, including after signing in with Entra ID
- User lockout after too many failed attempts, with every attempt logged
Session
- The session travels in an HttpOnly, strict SameSite cookie: page code can’t read it
- The screen locks after a configurable idle period
- HTTPS connection
Authorization
- Per-group permissions to view, create, edit and approve on each screen
- The company comes from the authenticated session, never from what the browser sends
- Read-only external links with expiry and a per-IP request limit
Data
- Audit trail, signatures and closed records protected by the database against changes and deletion
- Signature with a one-time code valid for a single record
- Every deletion is recorded in the audit trail before it runs
Perimeter
- The external portal is a separate application, on its own site and HTTPS only
- A portal token isn’t valid in the internal application, and vice versa
- Third-party attachments scanned with Microsoft Defender, with an extension allowlist
- The API only accepts calls from configured web origins
Audit
- Every action in every module and every sign-in is logged
- Risk-based audit trail review with signed closure
- Error log available to administrators
Architecture
What gets installed, and where.
Technology an IT team already knows how to run: Windows Server, IIS and SQL Server.
Browser
Internal users. Nothing to install.
Application server
IIS with the web application and the .NET 8 API.
Database
SQL Server: one record for all nine modules.
KulturPro BPMS
Optional: its own process under /bpms, with the same database and sign-in.
Printing workstations
Local agent only where controlled copies are printed; it serves its own machine only.
PLCs and tablets
Process variables and batch record capture, with a heartbeat for every channel and device.
External portal
Its own IIS site, with an HTTPS certificate and its own signing key.
Attachment scanner
Microsoft Defender on the portal server.
Microsoft Entra ID
Corporate sign-in.
SMTP email
Your company mail server.
AI provider
Only if the company enables the writing assistant.
Requirements
What your IT team needs.
| Component | Requirement | Required |
|---|---|---|
| Application server | Windows Server with IIS and the .NET 8 hosting bundle | Yes |
| Database | SQL Server | Yes |
| Users | Modern web browser | Yes |
| External portal | Its own IIS site with a public name and HTTPS certificate | Portal only |
| Attachment scanning | Microsoft Defender on the portal server | Portal only |
| Controlled printing | Print agent on each printing workstation | If printing |
| Business processes (BPMS) | Its own application pool on the same IIS site, under /bpms | BPMS only |
| Company SMTP server | Recommended | |
| Directory | Microsoft Entra ID or Active Directory | Optional |
Operations
Deployment and continuity.
Separate environments
Test and production are distinct environments, and the application identifies which one it runs in. Installation qualification verifies it.
Documented deployment
A step-by-step procedure with verification at the end, and database scripts that can be re-run without altering data.
Document contingency
Document management issues, in one go, a controlled PDF copy of every effective document, so you can operate if the system is unavailable.
Validation per environment
The installation protocol (IQ) is executed in each environment before operational qualification.
Questions
What IT security usually asks.
Where is the suite hosted?
It runs on Windows Server, IIS and SQL Server. The specific hosting is defined with your IT team during implementation.
Can one company see another company’s data?
No. The company is taken from the authenticated session on the server, never from data the browser sends, so another company’s information can’t be requested by altering a request.
What data goes to third-party services?
Only what the services your company enables need: Entra ID authentication, email through your SMTP server, and the text an author sends to the AI assistant. Malware scanning runs on your own server.
What happens if someone tries to guess a password?
The user is locked after several failed attempts, and every attempt is logged with its result.
Can a supplier reach the internal application from the portal?
No. The portal is a separate application with its own key: its credentials aren’t valid in the internal application, and the internal application rejects its tokens.
Review the architecture with your IT team.
We’ll send you the requirements and answer your security questionnaire before implementation.