User guide

Roles and what they can do

Every user has one role. Testers belong to a Team Lead, and Team Leads report to a manager (an AVP). This hierarchy decides which projects each person sees.

"Within scope" means projects the user leads, or projects whose tester belongs to the user's team. Permissions are enforced by the server, not just hidden in the interface.

The table shows the defaults. An Admin can change them under Settings > RBAC, which lists every feature covered by access control (63, in 10 groups: Dashboard, Projects, Findings, Vulnerability Database, Reports, Report Templates, Quiz, Users, Retention, Updates) with a switch per role for AVP, Team Lead and Tester. Admins always have every feature, and the switch for Admin is locked on. The Settings panel is not a feature: it is only ever available to Admins. A switch decides whether a role may use a feature at all; the scope rules above (own projects, own team) still apply on top of it. Changes apply to everyone as soon as they are saved, and a menu item or button disappears for a role that has lost the feature. Reset to defaults restores the table above.

Projects

1. Open Projects and choose New project.
2. Choose the compliance category (VAPT, PCI, CERT-In or ASV) and the testing type: Web, API, Mobile, Thick Client, Network or SCR.
3. Fill in client, scope, dates, testing environment and the report details. These are entered once and reused in every report. Client SPOC fields appear for CERT-In projects. SHA-1 is asked for Mobile, Thick Client and SCR projects.
4. SCR projects also ask for the Code Location and the Scanning System Username and Hostname (printed as {Code Location}, {system username} and {system hostname}), and do not ask for Testing Approach or Types of Login System.

• Status updates automatically: Not started when created, In progress when the first finding is added, and Completed when a report is generated.
• Compliance status (Compliant, Non-Compliant, In-Progress) is set by you and printed in reports.
• Completed projects stay editable by authorized users. Every field change is recorded, and Team Leads, AVPs and Admins can see the change history on the project page.
• Press Ctrl+K to search projects you can open.
• Hover tips throughout PMIS appear after one second.

Findings and evidence

1. On a project, add a finding by choosing a vulnerability from the library, so the standard wording is reused.
2. Add the project-specific details: affected URLs or hosts, authentication type, dependencies and notes.
3. If the library's CVSS score does not fit, set an override score and vector for this finding.
4. Add numbered proof-of-concept steps. A reminder asks you to make sure no sensitive information is included in screenshots or steps. Each step has a description and one or more screenshots (PNG, JPG, GIF or WebP, up to 20 per step). Screenshots print under their step in the order shown, which you can change with the arrows, and each one gets a thin black border in the Word report.
5. On Network projects the steps and PoC section is hidden for VA findings: the evidence comes from the Nessus scan output.

Findings that are not in the library

• Both options below are buttons in the Add Finding dialog, next to Cancel and Continue.
• Add Manually: enter the vulnerability yourself: name, severity, CVSS score and vector (a calculator is built in), description, impact, remediation, reference and optional CVE and CWE IDs. The finding is created in this project at once.
• Sync Vuln DB (a slider, on by default): also sends the vulnerability to the library as a normal approval request. The finding stays usable whatever the decision, and nothing is published without approval. Switch it off to keep the finding in this project only; there is no later sync for it.
• Import Project Findings: add many findings as PT findings (in a Network project they appear under PT Findings) from a .csv or .xlsx file (up to 100 MB and 5,000 rows) using the sample template’s exact headers. The i beside the button lists the accepted files and the exact header row. You see a preview first; if any row is invalid, nothing is imported. Rows already in the project are skipped. Imported findings stay in this project only: they never enter the library and have no sync option. Workbooks with formulas, macros or embedded objects are rejected.

Both kinds are treated like findings picked from the library: they need steps and screenshots before a report, and they appear in the project’s reports and Issue Log only.

Network projects and scan imports

Network projects support vulnerability assessment (VA) and penetration testing (PT) activities, and three kinds of import:

Nessus CSV files are read whatever way they were saved: commas, semicolons or tabs between columns, UTF-8 or UTF-16 text, and stray control characters in plugin output (replaced by a space). Only a file with binary data at its start, or without the Plugin ID, Name, Risk and Host columns, is refused, with a message saying why. If an upload fails, the message says whether the connection dropped while uploading, or the server stopped after the whole file had arrived, and a Try again button repeats the check.

• Nessus findings belong to that project only. They are not added to the shared vulnerability library.
• All VA findings imported into a project can be deleted together with Delete All VA Findings.

SCR (Secure Code Review) projects

SCR is a Testing Type (Platform) that uses the same project fields as a Cert-In Application project. Two imports are available on its Findings page:

• The project's Details page shows the imported Site Map below Tools Used.
• Fortify findings belong to that project only and are not added to the shared vulnerability library. Delete All Fortify Findings removes them together.
• For PCI and VAPT, upload the template with SCR as its Activity Type. For Cert-In, upload a template with SCR as its Activity Type; an SCR project never falls back to the Application template.
• SCR reports leave the CVSS score and vector placeholders empty.

Vulnerability library

• When someone submits a new vulnerability, Admins, AVPs and Team Leads get a notification. Clicking it opens the Pending Approval tab and highlights that request; if it has already been reviewed you are told so. Only those roles can open the tab or read pending records, whatever the link says.
• Everyone can search, filter by severity and export the library as CSV.
• New entries: Testers and Team Leads submit a request. It stays pending until an Admin, AVP or Team Lead approves it. The requester is notified of the decision.
• Edits: Testers propose changes to an existing entry. The original stays unchanged until the request is approved.
• Admins can add, edit or remove entries directly. They can also bulk upload a CSV or XLSX file in one of two modes: Replace swaps the whole library; Merge adds to it and asks which version to keep when names clash. Download the sample file from the page for the exact column format.

Dashboards, notifications and live users

• Dashboard: Testers see their own work, Team Leads their team, and AVPs and Admins the whole organisation.
• Notifications: the bell shows library decisions, new users, assignments, system updates and quiz reveals. Selecting a notification opens the related page. An Admin chooses, per notification type, which roles (AVP, Team Lead, Tester) receive it under Settings > Notifications. Admins always receive all of them.
• Live users: the count next to System Online. Admins, AVPs and Team Leads can open a list of active and idle users within their scope.

Retention

PMIS deletes old data automatically, once an hour, under two Admin-configurable policies in Settings:

The Retention page shows when each completed project is due for deletion. Download the reports you need before that date.

Quiz

• Admins schedule security quiz questions. Each question can be answered for 24 hours after it goes live.
• After the reveal you see the answer and explanation for questions you attempted. Late answers are recorded but not scored.
• The scorecard shows your points, streaks and badges. Leaderboards rank players and teams, and Team Leads can rename their team.

Admin tasks

• Users: create, edit, bulk upload (CSV or XLSX), reset passwords and reactivate accounts. Reset users must set a new password at next sign-in.
• Deleting a user deactivates the account immediately. Reactivating within 24 hours restores it with its data. After 24 hours, the data and files of projects the user owns are purged permanently.
• Templates: see Reports.
• Settings: application name, logo and favicon (browser tab, sidebar, login page), colours, table density, rows per page, severity names and colours (also printed in reports), session timeout, password policy, retention periods, storage and database size quotas (enforced: uploads are refused at the storage quota; creating or changing data is refused with HTTP 507 at the database quota, while viewing, deleting and Settings keep working), the largest file allowed for each accepted upload format (Attachments), which roles get which notifications, which roles may use each feature (RBAC), Issue Log columns, and date, time and number formats. Every setting takes effect for everyone once saved. Every change is recorded, with the person’s name and role, in the settings history.
• Updates: the About page shows the running version and newer releases. On a Docker installation, update by following Upgrading.