> ## Documentation Index
> Fetch the complete documentation index at: https://kb.manage.management/llms.txt
> Use this file to discover all available pages before exploring further.

# MRI Security & Compliance

> Security measures, data protection, and compliance for the MRI integration

## Security Overview

The MRI integration implements enterprise-grade security measures to protect your data throughout the synchronisation process.

<Info>
  All security measures comply with UK GDPR, the Data Protection Act 2018, and RICS best practices.
</Info>

## Credential Security

### Vault Encryption

API credentials are encrypted at rest using Supabase Vault:

* **Encryption:** AES-256-GCM
* **Key Management:** Automatic key rotation
* **Access:** Row-level security policies

```sql theme={null}
-- Credentials are never stored in plain text
SELECT store_mri_credentials_secure(
  building_id,
  client_id,
  encrypted_client_secret,  -- AES-256 encrypted
  api_base_url,
  environment
);
```

### Credential Rotation

<Warning>
  Rotate your MRI API credentials every 90 days as a security best practice.
</Warning>

The system tracks credential age and alerts directors when rotation is due:

| Age        | Status      | Action             |
| ---------- | ----------- | ------------------ |
| 0-60 days  | 🟢 Current  | No action needed   |
| 60-90 days | 🟡 Due Soon | Plan rotation      |
| 90+ days   | 🔴 Overdue  | Rotate immediately |

## Data Protection

### Data in Transit

* All API calls use **TLS 1.3** encryption
* Certificate pinning for the MRI MIX API
* No sensitive data in URL parameters

### Data at Rest

* Database encrypted with AES-256
* Backups encrypted with separate keys
* Point-in-time recovery enabled

### Data Minimisation

Only essential data is synchronised:

<AccordionGroup>
  <Accordion title="Synced Data">
    * Property and unit details
    * Tenancy information
    * Financial transactions
    * Contact business details
    * Maintenance records
    * Compliance documents
  </Accordion>

  <Accordion title="Not Synced">
    * Personal bank account numbers
    * National Insurance numbers
    * Passport/ID copies
    * Medical information
    * Criminal records
  </Accordion>
</AccordionGroup>

## Access Control

### Role-Based Access

Only authorised users can configure or access MRI integration:

| Role                  | Permissions                            |
| --------------------- | -------------------------------------- |
| **Building Director** | Full access to configuration and data  |
| **Property Manager**  | View sync status, trigger manual syncs |
| **Homeowner**         | View own synced data only              |
| **Super Admin**       | Full access across all buildings       |

### Row-Level Security

Supabase RLS policies ensure users only access their authorised buildings:

```sql theme={null}
-- Users can only access MRI data for their buildings
CREATE POLICY "mri_data_access" ON mri_properties
  FOR SELECT USING (
    building_id IN (
      SELECT building_id FROM building_users
      WHERE user_id = auth.uid()
    )
  );
```

## Audit Logging

### What's Logged

All integration activities are logged for compliance and security monitoring:

**Security Events:**

* ✅ Credential storage and updates
* ✅ Credential access (every retrieval is logged)
* ✅ Credential rotation events
* ✅ API authentication attempts (success and failure)
* ✅ Failed authentication attempts with IP addresses

**Operational Events:**

* ✅ Sync operations (start, complete, errors)
* ✅ All API calls (endpoint, method, HTTP status)
* ✅ Data modifications from sync
* ✅ Configuration changes
* ✅ Manual overrides and conflict resolutions
* ✅ Rate limit violations

### Log Entry Details

Each audit log entry includes:

```json theme={null}
{
  "id": "uuid",
  "table_name": "mri_credentials_secure",
  "record_id": "building-uuid",
  "action": "CREDENTIAL_ACCESS",
  "changed_by": "user-uuid",
  "building_id": "building-uuid",
  "ip_address": "192.168.1.1",
  "user_agent": "Mozilla/5.0...",
  "old_values": {...},
  "new_values": {...},
  "created_at": "2025-12-23T10:00:00Z"
}
```

### Log Retention

| Log Type      | Retention | Purpose                           |
| ------------- | --------- | --------------------------------- |
| Sync logs     | 90 days   | Operational troubleshooting       |
| Audit logs    | 7 years   | Compliance and legal requirements |
| Error logs    | 1 year    | System reliability monitoring     |
| Security logs | 7 years   | Security incident investigation   |

### Accessing Audit Logs

Building directors can view audit logs in the MRI Integration settings:

1. Navigate to **Settings** → **Integrations** → **MRI**
2. Click the **Security** tab
3. View the **Audit Log** section

<Tip>
  Use the search and filter options to find specific events or time periods.
</Tip>

## Compliance

### GDPR Compliance

<Check>Data processing agreement with MRI Software</Check>
<Check>Data processing on customer's MRI server infrastructure</Check>
<Check>Data subject access request support</Check>
<Check>Right to erasure implementation</Check>

### Data Processing Agreement

MRI data is processed on the customer's own MRI server (on-premise or hosted). We have:

1. **DPA in place** with MRI Software
2. **Data location** depends on customer's MRI deployment
3. **Data breach notification** procedures agreed

### Security Checklist

#### Weekly

* [ ] Review sync error logs
* [ ] Check for failed authentications

#### Monthly

* [ ] Audit user access permissions
* [ ] Review credential access logs
* [ ] Check sync performance metrics

#### Quarterly

* [ ] Rotate MRI credentials
* [ ] Security assessment
* [ ] Review DPA with MRI

## Technical Security Details

### Defense in Depth

The MRI integration implements multiple security layers:

| Layer           | Implementation             | Purpose                     |
| --------------- | -------------------------- | --------------------------- |
| **Application** | HTTP Basic Auth over HTTPS | Secure API access           |
| **Transport**   | TLS 1.3 encryption         | Protect data in transit     |
| **Storage**     | AES-256-GCM encryption     | Protect credentials at rest |
| **Database**    | Row Level Security (RLS)   | Enforce access control      |
| **Audit**       | Comprehensive logging      | Detect security incidents   |
| **Network**     | Rate limiting & timeouts   | Prevent abuse               |

### Credential Security Architecture

```mermaid theme={null}
graph TD
    A[Building Director] -->|Enters credentials| B[Frontend]
    B -->|HTTPS/TLS 1.3| C[Supabase Edge Functions]
    C -->|Encrypt with AES-256| D[Supabase Vault]
    D -->|Store encrypted| E[(Database)]
    F[Sync Service] -->|Request credentials| C
    C -->|Decrypt & return| F
    C -->|Log access| G[Audit Log]
```

**Key Security Features:**

1. **Never in Plain Text** - All credentials are encrypted before storage
2. **Vault-Only Storage** - Secrets stored in Supabase Vault, not regular database columns
3. **Access Logging** - Every credential retrieval is logged with user ID, IP, and timestamp
4. **Building Scoped** - Each building has separate credentials (no cross-contamination)
5. **RLS Enforcement** - Database policies prevent unauthorized access

### HTTP Basic Auth Security

**Credential Lifecycle:**

1. **Storage** - All MIX API credentials (Client ID, Database Name, User Name, Partner Key, Password) encrypted in Supabase Vault with AES-256-GCM
2. **Retrieval** - Credentials decrypted server-side only when needed for API calls
3. **Usage** - Base64-encoded credentials included in Authorization header over HTTPS
4. **Isolation** - Each building has separate credentials (no cross-contamination)
5. **Rotation** - Credentials can be rotated independently per building

**Security Measures:**

* ✅ Credentials never exposed to frontend/browser
* ✅ All API calls over TLS 1.3 only
* ✅ No credential storage in localStorage or cookies
* ✅ Every credential access logged with user ID and IP
* ✅ Supabase Vault automatic key rotation

### Data Encryption

**At Rest:**

* Database: AES-256 encryption
* Vault secrets: AES-256-GCM with automatic key rotation
* Backups: Encrypted with separate keys
* Point-in-time recovery: Encrypted snapshots

**In Transit:**

* TLS 1.3 for all API communications
* Certificate pinning for MRI MIX API
* No sensitive data in URL parameters
* Bearer tokens in headers only

### Row Level Security (RLS) Policies

The integration enforces strict access control at the database level:

```sql theme={null}
-- Only building directors can access credentials
CREATE POLICY "canonical_mri_credentials_all" ON mri_credentials
  FOR ALL TO authenticated
  USING (
    is_super_admin() OR
    is_building_director(building_id)
  );

-- Users can only view MRI data for their buildings
CREATE POLICY "mri_data_access" ON mri_properties
  FOR SELECT USING (
    building_id IN (
      SELECT building_id FROM building_users
      WHERE user_id = auth.uid()
    )
  );
```

**RLS Benefits:**

* ✅ Enforced at database level (can't be bypassed)
* ✅ Automatic filtering of unauthorized data
* ✅ Protection against SQL injection
* ✅ Multi-tenant data isolation

## Incident Response

### Immediate Actions

If you suspect a security issue:

<Steps>
  <Step title="Disable Integration">
    Immediately disable the MRI integration in **Settings** → **Integrations** → **MRI**
  </Step>

  <Step title="Contact Security Team">
    Email **[security@manage.management](mailto:security@manage.management)** with details of the incident
  </Step>

  <Step title="Document Everything">
    Note what you observed, when it happened, and any error messages
  </Step>

  <Step title="Preserve Logs">
    Do not delete any logs - they're crucial for investigation
  </Step>
</Steps>

### Investigation Queries

Building directors can run these queries to investigate suspicious activity:

**Check recent credential access:**

```sql theme={null}
SELECT
  created_at,
  changed_by,
  action,
  ip_address,
  user_agent
FROM mri_audit_log
WHERE table_name = 'mri_credentials_secure'
AND action IN ('CREDENTIAL_ACCESS', 'CREDENTIAL_STORED', 'CREDENTIAL_ROTATED')
AND created_at > NOW() - INTERVAL '7 days'
ORDER BY created_at DESC;
```

**Check failed authentication attempts:**

```sql theme={null}
SELECT
  created_at,
  action,
  error_message,
  ip_address
FROM mri_audit_log
WHERE action = 'AUTHENTICATION_FAILED'
AND created_at > NOW() - INTERVAL '24 hours'
ORDER BY created_at DESC;
```

### Breach Notification

In the event of a data breach:

* **72-hour notification** to ICO (UK GDPR requirement)
* **Immediate notification** to affected building directors
* **Incident report** provided within 7 days
* **Remediation plan** implemented immediately

<Warning>
  For urgent security incidents outside business hours, email [security@manage.management](mailto:security@manage.management) with "URGENT" in the subject line.
</Warning>

## Security Best Practices

### For Building Directors

<Check>Rotate MRI credentials every 90 days</Check>
<Check>Review audit logs monthly</Check>
<Check>Use strong, unique passwords for MRI account</Check>
<Check>Enable two-factor authentication on your Manage.Management account</Check>
<Check>Only share credentials with authorized directors</Check>
<Check>Immediately revoke access for departed directors</Check>

### For Property Managers

<Check>Maintain separate credentials for each building</Check>
<Check>Document credential rotation procedures</Check>
<Check>Train staff on security best practices</Check>
<Check>Monitor sync error logs for anomalies</Check>
<Check>Conduct quarterly security reviews</Check>

## Compliance Certifications

### Current Compliance

<CardGroup cols={2}>
  <Card title="SOC 2 Type II" icon="shield-check">
    Supabase infrastructure is SOC 2 Type II certified
  </Card>

  <Card title="UK GDPR" icon="scale-balanced">
    Full compliance with UK data protection regulations
  </Card>

  <Card title="ISO 27001" icon="certificate">
    Information security management system certified
  </Card>

  <Card title="EU-UK Data Transfer" icon="globe">
    Standard Contractual Clauses in place for international transfers
  </Card>
</CardGroup>

### Data Processing Agreement

Our DPA with MRI Software includes:

* ✅ Purpose limitation and data minimization
* ✅ Security measures and encryption requirements
* ✅ Sub-processor agreements
* ✅ Data breach notification procedures (72 hours)
* ✅ Data subject rights support (access, erasure, portability)
* ✅ Audit rights and compliance monitoring