Retrieve the triggering SQL statement as is
Have a look at MS-Docs about DBCC INPUTBUFFER


  Displays the last statement sent from a client to an instance of Microsoft SQL Server.


Add WITH NO_INFOMSGS just to suppress all informational messages.

Permissions

On SQL Server requires one of the following:


User must be a member of the sysadmin fixed server role.
User must have VIEW SERVER STATE permission.
session_id must be the same as the session ID on which the command is being run.





CREATE TABLE Test (Id int PRIMARY KEY, Val varchar(10));
CREATE TABLE Audit (Id int IDENTITY PRIMARY KEY, EventType NVARCHAR(30), Parameters INT, EventInfo NVARCHAR(4000));
GO






CREATE TRIGGER AuditTest
ON Test
FOR INSERT, UPDATE, DELETE
AS
BEGIN
    INSERT INTO Audit EXEC('DBCC INPUTBUFFER(@@SPID) WITH NO_INFOMSGS');
END
GO






INSERT INTO Test VALUES(1, 'John');
GO



2 rows affected






INSERT INTO Test VALUES(2, 'Anna');
GO



2 rows affected






UPDATE Test SET Val='Peter' WHERE Id=1;
GO



2 rows affected






DELETE FROM Test WHERE Id=2;
GO



2 rows affected






SELECT * FROM Audit;
GO



Id | EventType      | Parameters | EventInfo                              
-: | :------------- | ---------: | :--------------------------------------
 1 | Language Event |          0 | INSERT INTO Test VALUES(1, 'John');    
 2 | Language Event |          0 | INSERT INTO Test VALUES(2, 'Anna');    
 3 | Language Event |          0 | UPDATE Test SET Val='Peter' WHERE Id=1;
 4 | Language Event |          0 | DELETE FROM Test WHERE Id=2;           



As sepupic has pointed out on his comments if you are using an stored procedure, DBCC INPUTBUFFER returns the EXEC sentence instead of the SQL statement.




CREATE PROCEDURE dbo.InsertTest(@Id int, @Val varchar(10))
AS
BEGIN
    INSERT INTO Test VALUES (@Id, @Val);
END
GO






EXEC dbo.InsertTest @Id=5, @Val='Peper';
GO



2 rows affected



Id | EventType      | Parameters | EventInfo                               
-: | :------------- | ---------: | :---------------------------------------
 1 | Language Event |          0 | INSERT INTO Test VALUES(1, 'John');     
 2 | Language Event |          0 | INSERT INTO Test VALUES(2, 'Anna');     
 3 | Language Event |          0 | UPDATE Test SET Val='Peter' WHERE Id=1; 
 4 | Language Event |          0 | DELETE FROM Test WHERE Id=2;            
 5 | Language Event |          0 | EXEC dbo.InsertTest @Id=5, @Val='Peper';



dbfiddle here

Let me suggest you another approach, instead of store SQL commands, you can keep track of all changes of your data on this way:

1- Create a duplicate of your table and add some audit fields like, action, date, user, etc.




CREATE TABLE Test (Id int PRIMARY KEY, Val varchar(10));
CREATE TABLE Audit (Action varchar(10), CreatedAt datetime, [User] nvarchar(128), Id int, Val varchar(10));
GO



2- Lets the trigger to store all new changes.




CREATE TRIGGER AuditTest
ON Test
FOR INSERT, UPDATE, DELETE
AS
BEGIN
    DECLARE @Action varchar(10);
    IF EXISTS(SELECT 1 FROM inserted) AND EXISTS(SELECT 1 FROM deleted)
        SET @Action = 'UPDATE'
    ELSE IF EXISTS(SELECT 1 FROM inserted)
        SET @Action = 'INSERT'
    ELSE
        SET @Action = 'DELETE';

    IF @Action = 'UPDATE' OR @Action = 'INSERT'
    BEGIN
        INSERT INTO Audit
        SELECT @Action, GETDATE(), SUSER_NAME(), Id, Val
        FROM   inserted;
    END
    ELSE
    BEGIN
        INSERT INTO Audit 
        SELECT @Action, GETDATE(), SUSER_NAME(), Id, Val
        FROM   deleted;
    END
END 
GO



Now the final result will show something like this:




SELECT * FROM Audit;
GO



Action | CreatedAt           | User                                    | Id | Val  
:----- | :------------------ | :-------------------------------------- | -: | :----
INSERT | 01/08/2017 15:05:03 | fiddle_404da64bd81c4665970c0b39386771b0 |  1 | John 
INSERT | 01/08/2017 15:05:03 | fiddle_404da64bd81c4665970c0b39386771b0 |  2 | Anna 
UPDATE | 01/08/2017 15:05:03 | fiddle_404da64bd81c4665970c0b39386771b0 |  1 | Peter
DELETE | 01/08/2017 15:05:03 | fiddle_404da64bd81c4665970c0b39386771b0 |  2 | Anna 
INSERT | 01/08/2017 15:05:03 | fiddle_404da64bd81c4665970c0b39386771b0 |  5 | Peper



And it doesn't matter if you use a direct command, an stored procedure or you're calling it from an external application.

dbfiddle here