Redmine records every field change on every issue, permanently and per user, which is the property that matters most in a regulated environment. RedminePRO runs it on AWS in the region you choose, inside HAZERCLOUD's ISO/IEC 27001-certified information security management system.
Redmine keeps a journal on every issue. Each entry records who made the change, when, the field that changed, and both the old and the new value — status, assignee, priority, due date, any custom field. Comments are journal entries too. The history is displayed on the issue and it accumulates; the design intent is a permanent record rather than a current state. That is the difference between a tool that holds your process and a tool that can evidence it. When a reviewer asks who approved a change on 14 March, why the target date moved twice, or who reassigned an item before it closed, the answer is on the issue, in order, with names and timestamps.
Two things follow that are worth planning for. First, this only works if the process runs in the system rather than in a chat thread summarized into it afterward, so the configuration should make the tracker the path of least resistance. Second, journal history is data like any other — covered by the same backups, the same encryption and the same export, so you can pull it through the API or a CSV export whenever an auditor wants it in their own format. Whether administrators can edit or delete journal entries on your deployment, and any retention control you need, are worth confirming with us directly for your specific control environment rather than assuming.
Redmine's permission model is role-based and granular, which is what makes it usable when different groups must see different things inside one system.
Roles carry permissions, and users get roles per project. The same person can be a manager on one project and a reporter on another. Permissions are individually toggled — view issues, add issues, edit issues, manage versions, view time entries, view private notes — rather than bundled into three fixed levels.
Issue visibility is a role setting. A role can be limited to seeing all issues, only issues it created or is assigned, or all except private ones. Issues can be marked private, and individual comments can be private notes visible to internal roles while the rest of the thread stays open to a wider group.
Workflow gates are per role. Which status transitions each role can make is an explicit grid. So is field-level permission: a field can be required at one status, read-only at another, and invisible to some roles entirely. An approval gate that only a specific role can pass is configuration, not a plugin.
Groups make it maintainable. Assign roles to groups rather than individuals and access review becomes a review of group membership — the version an auditor can actually check. Because RedminePRO gives you full Redmine administrator access on every plan, this configuration is yours; you are not waiting on a support queue when someone changes team.
You choose your region at signup and your data resides in that region. RedminePRO operates in US, EU and India, on AWS; HAZERCLOUD is an AWS Advanced Tier Services Partner. Region is chosen at signup rather than switched later, so if you have a residency requirement it belongs in the first conversation. If the requirement is contractual — a specific jurisdiction named in a client agreement or a regulator's expectation — raise it with us directly and we will confirm in writing before you commit. Data-retention and deletion timelines are a standard procurement question; raise yours and we will answer it precisely rather than deflect.
HAZERCLOUD maintains active ISO/IEC 27001 certification covering its information security management system, and RedminePRO operates inside that certified ISMS. The certificate belongs to the operating company, not to the product — we state it that way because that is what the certificate covers. RedminePRO runs entirely on AWS data centers, which hold SOC 1, SOC 2, PCI-DSS and ISO/IEC 27001 certifications. Data is encrypted at rest with AWS KMS, FIPS 140-2 validated, AES-256, and in transit with TLS 1.2+. Backups are continuous and encrypted with point-in-time recovery. Passwords are salted and hashed and are not recoverable by staff. Staff access to customer data is restricted by job function, monitored, and only where support requires it. Payments run through Stripe, a PCI Service Provider Level 1.
RedminePRO does not hold SOC 2, HIPAA or NIS2 certification in its own right and does not claim to. Customers with those obligations do run on RedminePRO. The distinction between supporting your compliance program and holding a certificate is one your reviewers care about, and we would rather be the vendor that draws it for you. Full detail on the security page.
Send your reviewer to the security page first — the shared-responsibility split, certifications, encryption, backups, residency and access control are all published, and a good share of a standard questionnaire answers itself from it. Then send the questionnaire in whatever format your process produces, with your deadline attached, through the contact form or on a call. Expect one clarifying pass on questions written for a different class of vendor, and a direct no on anything we do not hold rather than a qualified yes. The enterprise page covers custom DPA and SLA terms, which is usually where financial-services procurement ends up.